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SUMMARY 


The  Mission  Reliability  Model  (MIREM)  has  been  developed  to  evaluate  the 
reliability  and  sustained  operating  Capability  of  advanced  electronic  circuits 
during  the  early  stages  of  development.  MIREM  is  applicable  to  integrated 
systems  that  achieve  fault  tolerance' through  dynamic  fault  detection,  fault 
isolation,  and  reconfiguration.  -The  model  can  also  be  valuable  in  evaluating 
designs  that  make  use  of^hard  wired^  or  ^brute  force***’  redundancy . 

The  most  unique  feature  of  MIREM  is  its  ability  to  accurately  reflect  the 
impact  of  reconf igurable,  competing  functions  on  system  reliability.  The  user 
defines  the  resources  necessary  to  support  a  required  function  (e.g.,  Identify 
Friend/Foe,  IFF),  and  the  model  will  compute  the  probability  of  losing  that 
functional  capability  over  a  certain  operating  time.  A  critical  failure 
occurs  when  there  are  not  a  sufficient  number  of  working  resources  to  support 
a  certain  function.  As  an  analytic  model,  MIREM  determines  a  specific  value 
for  Mean  Time  Between  Critical  Failure,  Mission  Completion  Success 
Probability,  and  Failure  Resiliency. 

This  report  documents  the  latest  enhancements  added  to  MIREM.  The  model 
can  now  calculate  the  effects  of  undetected  failures  and  false  alarms  upon 
system  reliability.  Mean  Time  Between  Maintenance  Action  and  Mean  Time  to 
Repair  are  two  output  statistics  which  have  been  added.  Graphical  outputs, 

now  included  with  MIREM,  illustrate  repair  options  for  circuits  where  _ _ 

reliability  gracefully  degrades  over  a  period  of  time.  ,  _ j  ,  ■  ' .  .  ■ 

This  users  guide  describes  all  features  of  the  model.  Sample  problems  are 
provided,  along  with  example  computer  runs,  which  illustrate  the  different 
ways  in  which  MIREM  can  be  used. 
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PREFACE 


This  report  provides  user  documentation  for 
MIREM,  a  program  for  evaluating  the  reliability  of 
advanced  fault- tolerant  systems  in  a  mission  scenario 
It  is  consistent  with  the  software  release  dated 
17  March  1986,  and  replaces  earlier  documentation 
dated  23  August  1985. 
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1 .  INTRODUCTION 


1 . 1  Overview 

The  Mission  Reliability  Model  (MIREM)  is  a  fault- tolerant 
system  reliability  program  developed  to  evaluate  the  mission 
reliability,  availability,  and  sustained  operating  capability 
of  advanced  electronics  systems  early  in  their  development 
phase.  These  systems  contain  integration,  redundancy,  and 
dynamic  reconfigurability  (self-repair)  as  part  of  their 
fault- tolerant  design.  Typical  analyses  that  can  be  conducted 
using  MIREM  include: 

1.  Evaluation  of  mission  reliability  for  alternative 
mission  scenarios. 

2.  Determination  of  the  additional  operating  time  with¬ 
out  repair  that  can  be  achieved  in  fault- tolerant  systems  in 
comparison  with  conventional  systems. 

3.  Identification  of  the  parts  within  a  system  that  are 
contributing  significantly  to  mission  failures. 

4.  Identification  of  design  improvements  that  offer  a 
large  payoff  in  mission  reliability. 

5.  Determination  of  the  increased  availability  that  can 
be  achieved  using  deferred  maintenance  policies. 


These  analysis  capabilities  are  provided  by  a  new  mathematical 
model  constructed  to  assess  a  broad  class  of  fault- tolerant 
structures . 

Program  MIREM  is  written  in  FORTRAN  77  for  operation  in  a 
large  variety  of  computer  installations.  Interactive,  full¬ 
screen  input-output  sessions  facilitate  convenient  operation. 
Graphical  output  is  provided  using  DI3000,  for  users  with 
graphics  terminals  or  plotters  and  D13000  software.  Figure  1 
shows  the  analysis  process  using  MIREM.  System  description 
data  available  during  the  development  phase  are  used  to  pre¬ 
pare  the  faul t- tolerant  structure  data  used  by  MIREM.  Base¬ 
line  architecture  and  scenario  files  are  then  created  using 
the  data  entry  program.  A  number  of  run  and  output  options  are 
selected  by  the  analyst  and  stored  in  scenario  files,  which 
are  then  executed  by  the  computational  program.  Graphical 


outputs  can  then  be  generated  by  running  the  plotting  program, 
The  analytic  (as  opposed  to  simulation)  approach  taken  in  the 
mathematical  model  results  in  very  fast  run  times  for  most 
scenarios  and  enhances  the  program's  utility  for  iterative 
"what  if"  investigations. 
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Figure  1. 


Overview  of  Analysis  Using  MIREM. 


The  MIREM  methodology  addresses  many  of  the  major  relia¬ 
bility  issues  for  advanced  systems: 

1.  Redundancy  at  the  Line  Replaceable  Unit  (LRU),  Line 
Replaceable  Module  (LRM) ,  and  component  levels. 

2.  Dynamic  reconfigurability  and  resource  sharing  that 


allow  several  system  functions  to  use  the  same  components  for 
primary  or  backup  operation. 

3.  Fault  recovery  software  that  allows  processing  to 


resume  when  computer  faults  occur. 

4.  Imperfect  switching  resulting  from  incomplete  Built- 


R 


5.  Modular  packaging  that  influences  redundancy  and  fault 
isolation  levels. 

6.  Deferred  repair  policies  that  exploit  fault  tolerance 
to  improve  availability. 

7.  Meaningful  measures  of  effectiveness  for  multifunction 
systems  in  a  mission  environment. 

The  methodology  also  applies  to  more  conventional  redundant 
systems.  The  model  does  not  estimate  component  failure  rates 
or  BIT  coverage;  reliability  estimates  derived  from  MIL-HDBK- 
217D,  parametric  analysis  for  Very  High  Speed  Integrated  Cir¬ 
cuits  (VHSIC)  parts,  or  by  other  techniques  are  accepted  as 
model  inputs.  Software  errors  are  also  not  considered  in 
the  model. 


1  •  2  Scope 

MIREM  is  applicable  to  advanced  integrated  electronic 
systems  that  achieve  fault  tolerance  through  dynamic  fault 
detection,  fault  isolation,  and  reconfiguration  (Figure  2). 
This  dynamic  process  allows  failed  items  to  be  replaced  by 
backups  or  items  which  were  originally  assigned  to  other 
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Figure  2.  Fault  Tolerance  Concepts 


functions.  Fault  detection/isolation  is  performed  by  BIT 
equipment,  which  isolates  faults  to  the  lowest  "failure  unit," 
referred  to  as  a  resource.  A  system  controller  tracks  func¬ 
tion  requirements  and  system  health  in  terms  of  failed  or  good 
resources.  When  a  failure  occurs  or  requirements  change,  the 
controller  will  reconfigure  the  system  in  an  attempt  to  meet 
the  function  requirements.  The  highly  integrated  nature  of 
these  systems  not  only  contributes  to  miniaturization  through 
commonality,  it  allows  fault  tolerance  and  graceful  degrada¬ 
tion  to  be  achieved  with  fewer  resources. 

MIREM  is  also  applicable  to  conventional  fault- tolerant 
systems  in  which  fault  tolerance  is  achieved  through  dedicated 
or  "brute- force"  redundancy.  When  applied  to  these  systems, 
MIREM  gives  the  same  results  as  the  well-known  Reliability 
Block  Diagram  (RBD)  analysis  technique. 


1.3 


Evolution  of  the  Model 


The  MIREM  methodology  was  developed  under  the  Impact 
Analysis  of  Integrated  Communication,  Navigation  and  Identifi¬ 
cation  Avionics  (ICNIA)  program.  The  ICNIA  system,  which  is 
currently  in  the  advanced  development  phase  under  the  direction 
of  the  Air  Force  Wright  Aeronautical  Laboratories  (AFWAL), 
will  integrate  16  radio  functions  into  a  highly  reconfigurable 
system.  The  MIREM  methodology  was  initially  implemented  in  a 
PL/1  program  and  used  to  analyze  the  ICNIA  system  definition 
study  architectures.  This  application  demonstrated  the  utility 
of  the  methodology.  System  engineers  from  ICNIA  contractor 
organizations  found  the  model  results  to  be  reasonable  and 
useful.  Several  additional  features  were  requested  by  them 
and  by  AFWAL  personnel . 

Under  a  second  phase,  the  methodology  was  enhanced  to 
include  the  features  that  had  been  requested.  The  enhanced 
model  was  programmed  in  FORTRAN  77  and  made  much  more  usable 
by  adding  interactive  data  entry,  input  data  checking  and 
error  messages,  and  improved  output  formats.  An  added  benefit 
of  the  FORTRAN  77  program  is  its  portability  to  a  variety  of 
computing  environments.  This  version  of  MIREM  was  tested  ex¬ 
tensively  against  the  PL/1  version  and  against  hand-calculations. 
It  has  been  used  by  Air  Force  personnel  and  contractors  to 
analyze  the  ICNIA  advanced  development  models. 

A  third  version  of  MIREM,  which  this  guide  addresses,  was 
created  to  respond  to  several  requests  for  additional  enhance¬ 
ments.  The  changes  between  this  and  the  previous  version  of 
MIREM  are  listed  in  Table  1.  These  changes  increase  the  accu¬ 
racy  of  MIREM  and  make  it  useful  in  addressing  logistics  support 
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Table  1.  New  Features 


Feature 

Outputs  Affected 

Imperfect  Switching 

(Undetected  Failures  and  False  Alarms) 

New  output  option 

Innovative  Repair  Policies 
and  Availability 

New  output  option 

Graphical  Output 

All 

Standby  Redundancy 

All 

General  Series-Parallel  Structures  (Groups) 

All 

Module  Removal  Rates 

LRM/LRU  Budget 

Exact  MCSP  Algorithm 

All  except  MTBFF 

Size  Changes 

None 

Increased  Input  Checking 

None 

issues  encountered  further  into  the  development  cycle,  and 
during  advanced  development  and  full-scale  development. 


1 . 4  Organization  of  the  Users  Guide 

A  description  of  the  reliability  model  is  presented  in 
Chapter  2.  This  description  includes  the  rationale  behind  the 
model  and  its  relationship  to  current  fault- tolerant  system 
reliability  techniques.  Detailed  mathematical  formulations 
are  provided  in  Appendix  A.  Chapter  3  provides  instructions 
on  how  to  prepare  model  inputs  from  typical  available  data 
sources.  User  instructions  for  operating  the  program  are 
given  in  Chapter  4.  Sample  studies  and  model  outputs  are  pre¬ 
sented  in  Chapter  5.  Some  advanced  applications  of  the  model 
that  require  more  careful  input  data  preparation  are  described 
in  Chapter  6.  A  sample  session  listing  is  reproduced  in  Ap¬ 
pendix  B.  Data  entry  forms  for  use  in  preparing  model  inputs 
are  provided  in  Appendix  C,  and  a  glossary  of  model  terminology 
is  found  in  Appendix  D. 


2. 


RELIABILITY  MODEL 


The  reliability  model  used  in  MIREM  has  two  main  dis¬ 
tinguishing  features: 

1.  The  complex  fault- tolerant  structures  found  in  dynam¬ 
ically  reconf igurable  systems  are  modeled. 

2.  The  multiplicity  of  functions  supported  in  highly 
integrated  systems  and  the  multifunction  nature  of  individual 
hardware  elements  are  modeled. 


A  network  model  is  used  to  represent  these  system  features  in 
a  reliability  structure.  Because  it  is  network-based,  MIREM 
is  more  economical  than  most  simulation-based  or  Markov-based 
models.  A  new  computational  approach  is  used  that  allows  real¬ 
istic  complexities  in  system  configurations  to  be  analyzed. 

In  addition,  a  database  that  is  organized  by  function  is  used, 
making  the  analysis  of  multifunction  systems  much  more  straight 
forward.  These  model  characteristics  make  MIREM  applicable  to 
a  broad  class  of  advanced  systems  and  necessitate  the  use  of 
mission-related  reliability  measures  (Sections  2.1  and  2.2). 
MIREM  computations  are  described  in  Section  2.3.  Finally,  the 
relationship  between  MIREM  analysis  and  the  more  traditional 
reliability  block  diagram  approach  is  explored  in  Section  2.4. 


2 . 1  Measures  of  Effectiveness 

The  multiplicity  of  functions  supported  by  these  systems 
and  their  varying  importance  to  different  operating  scenarios 
necessitate  a  combined  measure  of  effectiveness  for  reliability 
It  is  assumed  that  the  operating  profile  consists  of  a  single 
"mission"  that  is  repeated.  The  mission  may  contain  several 
phases,  each  of  which  involves  a  set  of  required,  or  critical, 
functions.  A  system  failure  or  critical  failure,  is  defined 
as  the  unavailability  of  a  critical  function  during  a  mission 
phase  in  which  it  is  required.  Using  this  definition  of  criti¬ 
cal  failures,  reliability  measures  are  defined  as  follows: 

1 .  Mission  Completion  Success  Probability  (MCSP)  -  the 
probability  that  one  mission  is  completed  without  a  critical 
failure  by  a  system  that  initially  contains  no  faults. 

2.  Mean  Time  Between  Critical  Failure  (MTBCF)  -  the  mean 
operating  time  until  a  critical  failure  occurs,  starting  with 
a  system  that  contains  no  faults. 


I  J  *  fcA  ||fl  l 


,  re  *  •-«  •'  tw  •  a^t  ^«4  ,>  •  ,ia  Jfc  — Jtar  JfM '  .'4  J«  ‘  f£*  Jta"*# »'  _tf*‘ . 


J.' JJ>u J^J.1 JU»  lA^TMjXjJJAj 


a 


3.  Failure  Resiliency  -  the  ratio  of  MTBCF  to  the  tradi¬ 
tional  Mean  Time  Between  Failure  (MTBF). 

Since  MTBF  refers  to  the  first  failure  in  the  system,  failure 
resiliency  is  greater  than  or  equal  to  1  and  can  be  roughly 
interpreted  as  the  average  number  of  failures  until  critical 
failure.  Larger  failure  resiliency  values  correspond  to  sys¬ 
tems  with  a  higher  degree  of  fault  tolerance.  The  MCSP  and 
MTBCF  measures  can  also  be  defined  for  single  functions  in¬ 
stead  of  for  mission  scenarios.  When  a  single  function  is 
being  considered,  MTBCF  will  be  referred  to  as  Mean  Time  Be¬ 
tween  Function  Failure  (MTBFF).  The  probability  that  a  single 
function  is  available  for  a  specified  duration  will  be  re¬ 
ferred  to  as  MCSP,  and  the  function  will  be  specified. 

The  following  maintainability/availability  measures  will 
be  used: 

1 .  Mean  Time  Between  Maintenance  Action  (MTBMA)  -  the 
mean  operating  time  until  system  repair,  starting  with  a 
fault-free  system.  Since  system  failure  always  causes  a  re¬ 
pair  action,  this  number  is  less  than  or  equal  to  MTBCF. 

2.  Mean  Time  To  Repair  (MTTR)  -  the  mean  time  to  repair 
the  system  by  removing  and  replacing  Line  Replaceable  Units 
(LRUs)  or  Line  Replaceable  Modules  (LRMs). 

3.  Inherent  Availability  -  the  ratio  of  MTBMA  to  MTBMA 
plus  MTTR~j  the  fraction  of  time  that  the  system  is  operational, 
neglecting  any  logistics  delays. 

4.  Probability  of  Removal  -  the  probability  that  an  LRM/ 
LRU  will  contain  a  fault  (and  therefore  be  removed)  upon  re¬ 
pair  of  the  system. 

Two  other  definitions  are  introduced  concerning  the  relative 
impact  of  LRMs/LRUs: 

1.  Marginal  MCSP  -  MCSP  given  that  no  failures  occur  in 
a  specified  LRM/LRU.  This  measure  ranges  from  system  MCSP  for 
an  LRM/LRU  that  makes  no  contribution  to  MCSP,  up  to  1  for  an 
LRM/LRU  that  dominates  MCSP. 

2.  Relative  Contribution  to  MCSP  -  the  probability  that 
repair  of  a  specified  LRM/LRU  could  restore  mission  capability 
when  a  critical  failure  occurs.  This  measure  ranges  from  0 
for  an  LRM/LRU  that  never  causes  critical  failure,  up  to  1  for 
an  LRM/LRU  that  dominates  MCSP. 
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All  of  these  measures  depend  on  the  repair  policy  being 
used;  i.e.,  the  decision  of  when  to  repair  the  system.  Four 
policies  will  be  considered: 

1.  Immediate  Repair  -  repair  any  faults  at  the  end  of 
each  mission. 

2.  Deferred  Repair  -  repair  only  when  a  critical  failure 
occurs. 

3.  Scheduled  Maintenance  -  repair  after  a  specified  oper¬ 
ating  time  or  when  a  critical  failure  occurs. 

4.  Repair  at  Degraded  Level  -  repair  when  the  number  of 
redundant  components  in  some  portion  of  the  system  falls  below 
a  specified  level;  these  repairs  include  repairing  when  a 
critical  failure  occurs. 


Not  all  of  the  performance  measures  can  be  computed  for  the 
last  two  repair  policies,  as  explained  in  Section  4.7. 


2 . 2  Mission  Scenarios 

A  mission  can  be  described  by  a  time  sequence  of  function 
requirements.  MIREM  assumes  that  the  mission  can  be  divided 
into  phases,  each  of  which  has  a  set  of  critical  functions. 

The  ability  of  the  system  to  support  the  requirements  during  a 
phase  will  also  depend  on  the  timing  of  function  requirements 
within  the  phase.  Because  the  specific  timing  is  generally 
unknown,  MIREM  considers  just  two  cases: 

(a)  All  functions  are  required  simultaneously  within  a 
phase . 

(b)  Each  function  is  required  independently  within  a  phase 

These  two  cases  bound  the  actual  mission  environment.  The 
worst  case  (a)  is  recommended  as  the  baseline  for  analysis. 

2.3  MIREM  Computational  Approach 


2.3.1  Resource  Failure  Model 

From  a  reliability  perspective,  the  system  is  considered 
to  be  a  collection  of  discrete  resources .  A  resource  fails  as 
a  unit  and  is  monitored  individually  by  the  system  controller 
for  reconfiguration  purposes.  Resources  correspond  to  func¬ 
tional  entities  in  the  system.  They  often  also  correspond  to 
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physical  entities,  such  as  LRMs.  Switches,  interconnections  j 

between  LRMs  or  LRUs,  BIT  hardware,  and  control  hardware  can 
all  be  included  as  resources  and  their  failures  considered. 

Software  failures  per  se  are  not  included  in  MIREM;  however, 
software  characteristics  that  affect  fault  recovery  and  recon¬ 
figurability  can  be  accounted  for  as  described  in  Section  2.3.2. 

All  resources  are  assumed  to  have  a  constant  failure  rate, 
expressed  as  failures  per  operating  hour,  while  they  are  acti¬ 
vated.  Each  portion  of  the  system  (each  pool)  can  be  modeled 
as  active  redundant,  with  all  resources  activated  and  subject 
to  failures  whenever  the  system  is  operating,  or  as  standby 
redundant,  with  resources  activated  only  when  they  are  being 
used  to  meet  the  mission  requirement.  To  satisfy  the  constant 
failure  rate  assumption,  individual  resources  should  not  con¬ 
tain  redundancy. 

2.3.2  System  Failure  Model 

The  basic  computation  performed  in  MIREM  is  to  evaluate 
the  probability  of  losing  a  specified  functional  capability 
("system"  or  "critical"  failure)  over  a  specified  operating 
time  without  repair;  all  other  computations  require  this  build¬ 
ing  block.  A  system  failure  is  defined  as  occurring  when  there 
are  insufficient  resources  to  perform  the  required  functions 
within  a  mission  phase.  This  computation  requires: 

1.  The  resource  failure  model  described  in  Section  2.3.1. 

2.  A  mapping  of  resource  failures  into  system  failures. 


Unfortunately,  traditional  approaches  to  evaluating  this  map¬ 
ping  are  practical  only  for  systems  with  a  certain  modular 
structure  that  does  not  always  apply  to  advanced  avionics 
architectures.  Furthermore,  it  is  desirable  to  represent  this 
mapping  for  individual  functions  rather  than  complete  missions, 
so  that  a  variety  of  missions  can  be  constructed  from  a  single 
database . 

For  a  broad  class  of  advanced  architectures,  it  is  pos¬ 
sible  to  take  advantage  of  the  special  structure  of  this  mapping 
to  compute  MCSP  efficiently.  The  computations,  as  implemented 
in  MIREM,  are  detailed  in  Appendix  A.  The  basic  approach  is 
to  assume  a  structure  corresponding  to  two  levels  of  reconfig¬ 
urability  or  switching.  This  type  of  structure  is  illustrated 
in  Figure  3. 


At  the  lowest  level,  pools  of  interchangeable  resources 
are  identified.  Branches  are  alternate  identical  paths  within 


Figure  3.  A  Two-Level  Structure  for  System 
Architecture  Representation. 


a  pool,  each  containing  one  or  more  resources  in  series.  Each 
function  utilizes  a  certain  number  of  branches  (or  fraction  of 
a  branch)  in  a  pool.  The  combined  resource  requirement  for  a 
set  of  required  functions  depends  on  a  number  of  timing  issues 
and  is  addressed  in  Section  2.3.3.  Given  a  total  resource 
requirement  of  k,  a  pool  with  n  parallel  branches  is  evaluated 
as  a  k-of-n  structure.  MCSP  for  a  set  of  series  pools,  called 
a  chain,  is  the  product  of  the  probability  that  each  pool  has 
sufficient  resources  operating. 

The  second  level  of  reconfiguration  is  between  parallel 
chains .  A  chain  is  a  set  of  pools  that  is  switched  (reconfig¬ 
ured)  as  a  group.  In  many  cases,  a  chain  will  correspond  to 
an  LRU  because  LRUs  have  separate  power  supplies  and  limited 
inter-LRU  connections.  A  set  of  functions  is  available  on 
parallel  chains  if  there  is  an  allocation  of  functions  to 
chains  such  that  each  chain  can  support  its  allocated  func¬ 
tions.  The  approach  to  evaluating  MCSP  on  parallel  chains 


consists  of  enumerating  all  possible  allocations  of  functions 
to  chains  (see  Appendix  A).  This  approach  is  computationally 
feasible  whereas  the  traditional  enumeration  of  resource 
states  is  not,  the  difference  being  that  there  are  many  more 
resources  than  required  functions. 

Communication  between  parallel  chains  is  also  modeled. 

For  example,  data  processors  in  dual  redundant  LRUs  may  share 
their  processing  load  through  a  data  bus.  This  is  modeled  by 
defining  shared  pool  pairs  (one  pool  in  each  chain)  that  have 
a  single  resource  requirement.  The  number  of  branches  in  this 
pool  pair  is  the  total  for  the  two  pools  if  both  chains  are 
operational;  however,  if  certain  other  pools  in  a  chain  fail, 
its  shared  pools  cannot  be  used. 

Traditional  series/parallel  structures  can  also  be  analyzed 
using  MIREM.  In  fact,  if  the  multifunction  capability  of  MIREM 
is  not  used,  parallel  chains  are  a  series-parallel  structure 
(actually  a  hierarchical  k-of-n  structure).  This  occurs  when 
only  one  function  is  critical  to  a  mission  or  when  there  is  no 
contention  between  functions  for  resources  (no  type  C  or  S 
pools,  as  defined  in  Section  2.3.3).  However,  using  parallel 
chains  restricts  the  model  to  two  levels  and  two  parallel  paths 
at  the  higher  level.  More  general  structures,  such  as  those 
shown  in  Figure  4,  can  be  modeled  in  MIREM  using  groups ,  which 
are  nested  k-of-n  structures.  . 


TRIPLE  REDUNDANCY 
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Figure  4.  Examples  of  Series/Parallel  Structures. 
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Total  system  MCSP  is  the  product  of  the  MCSP  for  each 
chain/parallel  chain  set.  Other  measures  of  effectiveness  can 
be  derived  from  MCSP.  Of  particular  importance  are:  MTBCF, 
which  is  computed  by  evaluating  and  numerically  integrating 
MCSP  for  different  operating  times;  and  failure  resiliency, 
which  is  calculated  as  the  ratio  of  MTBCF  to  MTBF. 

2.3.3  Resource  Requirements  Model 

A  practical  approach  to  determining  the  total  resource 
requirements  of  functions  that  dynamically  interact  is  to  class 
ify  resources  based  on  their  dynamic  features  and  then  treat 
them  accordingly  in  the  network  model  described  above.  Three 
types  of  resource  utilization  have  been  identified: 

1.  Contending:  Each  function  must  use  separate  resources 
The  functions  are  available  if  separate  resources  are  avail¬ 
able  for  each  function. 

2.  Timesharing:  Each  function  utilizes  a  resource  a 
fraction  of  the  time.  A  set  of  functions  is  available  if 
there  is  a  configuration  in  which  no  resource  is  overloaded. 

3.  Noncontending :  All  functions  can  use  the  same  re¬ 
sources.  The  functions  are  available  if  there  are  sufficient 
resources  for  the  most  demanding  function. 


Resources  are  contending  with  respect  to  certain  functions  if 
the  resources  must  be  dedicated  constantly,  or  at  rigidly 
scheduled  times,  to  supporting  the  functions  (e.g. ,  receivers 
used  to  monitor  communication  channels).  Resources  are  time- 
shared  if  they  are  utilized  by  a  function  at  flexibly  scheduled 
times  so  that  several  functions  can  be  interleaved  (e.g.,  data 
processors).  Resources  that  can  be  used  by  any  number  of  func¬ 
tions  simultaneously  (e.g.,  power  supplies)  are  always  non¬ 
contending  . 

The  classification  of  resources  as  contending,  noncontend¬ 
ing,  or  timesharing  also  depends  on  the  times  during  a  mission 
phase  at  which  each  function  is  required.  If  functions  are 
not  required  simultaneously,  their  resources  are  noncontending. 

MIREM  assumes  that  the  type  of  resource  utilization  can 
be  identified  at  the  pool  level;  i.e.,  all  resources  within  a 
pool  are  utilized  in  the  same  manner.  Resource  requirements 
are  calculated  according  to  four  pool  types  that  result  from 
the  resource  utilization  options: 
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N:  noncontending  pools,  excluding  type  F 

C:  contending  or  timesharing  pools,  excluding 

type  S 

S:  shared  pools;  i.e.,  contending  or  timesharing 

pool  pairs  in  parallel  chains  that  share 
requirements 

F:  chain-fail  pools;  i.e.,  noncontending  pools 

that  must  be  operating  for  any  of  the  pools 
in  the  chain  (including  type  S  pools)  to  be 
used . 


Resource  requrements  for  type  N  and  type  F  pools  are  the  max¬ 
imum  of  the  individual  function  utilization  rates.  Resource 
requirements  for  type  C  and  type  S  pools  are  the  sum  of  the 
function  utilizations  for  simultaneous  mission  requirements. 

When  functions  are  not  required  simultaneously,  the  resource 
requirement  is  the  maximum  function  utilization. 

For  pools  in  a  parallel  chain,  the  required  functions  are 
only  those  allocated  to  that  chain.  Type  S  pools,  which  always 
occur  in  pairs  with  one  pool  in  each  parallel  chain,  must  sup¬ 
port  the  functions  allocated  to  both  of  the  chains.  Using 
these  procedures,  the  number  of  branches  (parallel  resource 
paths)  required  in  each  pool  is  determined.  These  requirements 
can  then  be  used  to  drive  the  system  failure  model  described 
in  Section  2.3.2. 

2.3.4  Repair  Model 

The  MCSP  calculation  of  Section  2.3.2  applies  to  an  oper¬ 
ating  period  during  which  there  is  no  repair.  Noncritical 
failures  accumulate  until  the  system  fails.  MIREM  also  con¬ 
siders  the  various  repair  policies  defined  in  Section  2.1. 

MCSP  and  maintainability  calculations  for  different  repair 
policies  are  discussed  in  this  section.  Because  the  deferral 
of  repairs  results  in  missions  being  started  in  various  de¬ 
graded  (but  still  mission-capable)  states,  a  single  MCSP  num¬ 
ber  does  not  apply.  Instead,  the  average  MCSP  of  a  fleet  of 
systems,  operated  under  a  repair  policy  until  they  have  reached 
a  steady-state  distribution  of  system  health,  will  be  considered. 

Immediate  Repair  -  Under  immediate  repair,  all  missions 
are  flown  with  a  fully  repaired  system.  The  MCSP  calculation 
of  Section  2.3.2  gives  the  average  MCSP.  MCSP  is  converted  to 
an  average  failure  rate  for  a  mission;  the  inverse  of  this 
failure  rate  is  MTBCF .  Since  all  failures  are  repaired,  MTBMA 
is  just  MTBF .  , 
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Deferred  Repair  -  Under  deferred  repair,  repair  corre¬ 
sponds  to  critical  failure;  i.e.,  MTBMA  is  equal  to  MTBCF. 
MTBCF  is  obtained  by  numerically  integrating  MCSP  over  differ¬ 
ent  operating  times  without  repair.  Average  MCSP  is  obtained 
from  the  average  failure  rate  corresponding  to  MTBCF. 

Scheduled  Maintenance  -  Under  scheduled  maintenance,  the 
system  must  operate  for  the  scheduled  maintenance  interval 
without  critical  failure.  MCSP  is  integrated  over  this  interval 
and  used  to  compute  MTBCF.  The  calculation  assumes  that  the 
scheduled  maintenance  "clock"  is  reset  when  a  critical  failure 
occurs.  MTBMA  is  obtained  by  summing  the  rate  of  noncritical 
repairs  at  the  scheduled  times  and  the  rate  of  critical  repairs. 

Repair  at  Degraded  Level  -  Under  this  policy,  repair 
occurs  when  the  number  of  good  branches  in  some  pool  drops 
below  a  specified  minimum  level  of  repair.  Reliability 
measures  are  calculated  only  for  systems  with  no  parallel 
chains  or  groups.  For  series  chains,  average  MCSP  is  cal¬ 
culated  by  first  deriving  the  steady-state  distribution  of  the 
number  of  branches  remaining  in  each  pool,  using  a  Markov 
model.  MCSP  for  each  number  of  branches  is  then  computed  and 
the  average  taken.  Pools  are  combined  using  an  approximation 
that  avoids  having  to  model  the  joint  state  space,  which  would 
have  too  many  states.  MTBCF  is  again  computed  by  converting 
average  MCSP  to  an  average  failure  rate. 

MTBMA  can  be  calculated  for  any  system  (including 
parallel  chains)  as  the  average  time  until  some  pool  falls 
below  its  minimum  repair  level.  It  is  obtained  by  numerical 
integration  over  time.  For  type  S  pool  pairs,  the  minimum 
repair  level  is  treated  as  the  combined  level  for  both  pools. 
Repair  occurs  when  either  pool  falls  below  half  of  the  repair 
level.  Because  of  this  special  treatment,  the  input  repair 
level  may  be  less  than  the  mission  requirement  for  type  S  pools 
(repair  levels  for  other  pool  types  must  meet  the  mission  re¬ 
quirements).  Hence,  MTBMA  for  parallel  chains  should  be 
viewed  as  approximate.  In  particular,  this  calculation  could 
give  an  MTBMA  greater  than  the  deferred  repair  MTBCF,  which  is 
incorrect . 

2.3.5  Imperfect  Switching  Model 

The  previous  sections  have  assumed  that  the  system  con¬ 
troller  always  selects  a  configuration  that  meets  the  mission 
requirements,  if  such  a  configuration  exists.  This  assumption 
requires: 
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1.  Perfect  knowledge  of  faults  from  BIT. 

2.  Optimal  reconfiguration  logic  in  the  controller. 


MIREM  contains  an  imperfect  switching,  or  BIT,  model  that  re¬ 
laxes  the  first  requirement  by  considering  undetected  failures 
and  false  alarms.  Undetected  failure  rates  and  false  alarm 
rates  are  specified  for  each  pool.  Mission  outcome  probabilities 
are  computed  for  three  cases: 

1.  Up  and  Believed  Up  -  the  critical  functions  were  sup¬ 
ported  and  the  system  controller  believes  they  were  supported. 

2.  Up  and  Believed  Down  -  the  critical  functions  were 
supported  but  the  system  controller  believes  they  were  not 
supported . 

3.  Down  -  the  critical  functions  were  not  supported. 


The  probability  that  the  system  is  up  using  the  imperfect  BIT 
model  (the  first  two  cases)  is  defined  as  the  imperfect  switch¬ 
ing  MCSP.  The  probability  that  the  system  is  incorrectly  be¬ 
lieved  to  be  down  (the  second  case)  is  defined  as  the  mission 
false  abort  probability . 

Imperfect  switching  causes  a  critical  failure  when  the 
controller  selects  a  configuration  in  which  a  resource  with  an 
undetected  failure  is  used,  or  when  false  alarms  make  the  con¬ 
troller  think  that  insufficient  resources  remain.  In  the 
latter  case,  it  is  assumed  that  a  configuration  will  still  be 
selected,  but  it  may  use  resources  with  detected  failures. 

The  exact  probabilities  of  these  events  depend  on  the  specific 
reconfiguration  logic  used.  MIREM  calculates  upper  and  lower 
bounds  that  apply  to  almost  any  reconfiguration  logic. 

For  imperfect  switching  MCSP,  the  lower  bound  is  obtained 
by  assuming  that  any  undetected  failure  will  cause  a  critical 
failure;  the  upper  bound,  by  assuming  that  the  resources  least 
prone  to  undetected  failures  will  be  used  and  neglecting  recon¬ 
figuration  due  to  failures.  False  alarms  are  neglected  in 
both  cases,  making  the  lower  bound  approximate.  Imperfect 
switching  MCSP  is  then  subtracted  from  perfect  switching  MCSP 
to  show  the  contribution  to  mission  failures.  Numerical  inte¬ 
gration  is  performed  to  compute  the  imperfect  switching  MTBCF. 

Two  approaches  are  used  to  bound  the  mission  false  abort 
probability.  The  first  is  to  subtract  p^  ,  the  probability 
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that  the  system  is  up  and  believed  up,  from  the  imperfect 
switching  MCSP.  Bounds  for  p^.  are  obtained  by  assuming  that 

all  components  with  undetected  failures  are  used  or  that  a 
minimum  of  them  are  used.  False  alarms  are  considered.  Be¬ 
cause  these  bounds  can  be  very  loose,  a  second  upper  bound  is 
also  computed  using  the  approach  described  in  Appendix  A. 8. 


2 . 4  Reliability  Block  Diagram  Interpretation  of  MIREM 

MIREM  considers  structures  (i.e.,  relationships  between 
resource  failures  and  system  failure)  that  cannot  be  drawn 
exactly  using  RBDs.  However,  it  can  be  very  useful  to  repre¬ 
sent  portions,  or  configurations,  of  a  MIREM  structure  using 
RBDs.  Several  RBD  interpretations  of  MIREM  are  suggested.  An 
example  of  a  single  function  (and  single  pool)  RBD  is  given  in 
Chapter  3. 

Single-Pool  RBD  -  Each  pool  with  pool  type  N,  C,  or  F  can 
be  drawn  as  an  active  k-of-n  RBD  once  the  functions  allocated 
to  the  chain  using  the  pool  are  specified.  The  type  S  pool 
pairs  can  be  drawn  as  a  k-of-n  RBD  once  the  required  functions 
are  specified,  assuming  that  certain  other  type  F  pools  do  not 
fail.  If  they  fail,  the  type  S  pool  pair  RBD  changes.  The 
following  rules  define  the  RBD: 

1.  The  resources  within  each  branch  of  the  pool  are  in 
series . 

2.  The  number  of  parallel  paths  (n)  is  the  total  number 
of  branches  in  the  pool  or  pool  pair. 

3.  The  number  of  required  paths  (k)  is  the  combined 
utilization  rate  of  the  pool  across  the  functions  using  the 
pool  or  pool  pair  as  defined  in  Section  2.3.3.  Fractional 
utilizations  are  rounded  upward. 


Single-Function  RBD  -  If  only  one  function  is  required, 
an  RBD  can  be  drawn  for  the  entire  perfect  switching  system 
except  that  if  the  system  contains  type  S  and  F  pools,  the 
type  S  pools  cannot  be  interpreted  exactly.  The  RBD  suggested 
here  neglects  the  interaction  between  type  S  and  type  F  pools. 
To  draw  the  RBD: 

1.  Form  a  k-of-n  RBD  for  each  pool  or  type  S  pool  pair, 
assuming  that  the  function  is  allocated  to  that  pool's  chain. 

2.  Form  an  RBD  for  each  chain  by  placing  the  type  N,C, 
and  F  pools  in  series.  Some  of  the  pools  may  have  0-of-n  (ir¬ 
relevant)  RBDs  for  a  given  function  and  can  be  omitted. 


3.  Form  an  RBD  for  each  parallel  chain  pair  by  placing 
the  two  chains  in  parallel  (l-of-2)  and  then  adding  each  type 
S  pool  pair  RBD  from  these  chains  in  series. 

4.  Form  the  system  RBD  by  placing  each  single  chain  and 
parallel  chain  pair  RBD  in  series. 


Chain  Allocation  RBD  -  One  level  at  which  dynamic  recon¬ 
figuration  can  occur  in  systems  modeled  by  M1REM  is  the  alloca¬ 
tion  of  functions  to  parallel  chains  (dynamic  reconfiguration 
also  occurs  within  pools).  If  the  configuration  is  restricted 
by  assuming  a  certain  allocation  of  functions  to  chains,  a 
perfect  switching  system  RBD  can  be  drawn  (disregarding  the 
interaction  between  type  S  and  type  F  pools).  The  RBD  will 
depend  on  the  required  functions  (the  mission)  and  the  chain 
allocation.  To  draw  the  RBD: 

1.  Form  an  RBD  for  each  pool  or  type  S  pool  pair  based 
on  the  functions  allocated  to  that  pool's  chain. 

2.  Form  an  RBD  for  each  chain  as  above. 

3.  Form  an  RBD  for  each  parallel  chain  pair  by  placing 
the  two  chains  in  series  (2-of-2)  and  then  adding  each  type  S 
pool  pair  RBD  from  these  chains  in  series.  If  a  chain  has  no 
functions  allocated  to  it,  it  can  be  omitted  from  the  RBD. 

4.  Form  the  system  RBD  as  above. 


Series  chains  with  groups  can  also  be  represented  by  RBDs 
once  the  required  functions  are  specified.  Each  group  is  a 
k-of-n  structure  containing  other  groups  or  pools  as  its 
branches . 


3.  INPUT  DATA  PREPARATION 


The  reliability  model  used  in  MIREM  requires  as  input  a 
fault- tolerant  system  structure.  Although  the  necessary  infor¬ 
mation  is  generally  available  as  soon  as  a  top-level  system 
design  emerges,  translating  this  information  into  a  fault  tree/ 
block  diagram/structure  function  can  be  a  formidable  task. 

The  data  structure  approach  used  in  MIREM  simplifies  this 
process.  This  chapter  provides  an  orderly  procedure  for 


identifying  MIREM  data  elements.  The  process  takes  place  off¬ 
line  and  results  in  data  entry  worksheets  which  can  then  be 
readily  keyed  in,  as  described  in  Chapter  4.  Input  data  pre¬ 
paration  for  certain  advanced  applications  that  require  ap¬ 
proximate  or  case-by-case  treatment  are  deferred  until  Chap¬ 
ter  6.  The  experienced  user,  when  dealing  with  relatively 
simple  architectures  (or  architecture  changes),  will  probably 
be  able  to  skip  many  of  the  off-line  steps  and  proceed  di- 
rectly  to  on-line  data  entry;  however,  knowledge  of  this 
chapter  will  still  be  required. 


3 . 1  Overview  of  Data  Requirements 

This  section  describes  the  data  requirements  for  con¬ 
ducting  an  analysis  with  MIREM  and  introduces  an  example 
architecture  which  will  be  used  throughout  this  manual.  MIREM 
requires  two  basic  types  of  data  to  define  an  architecture: 

1.  Structural  data  describing  which  system  resources  are 
required  to  perform  each  operational  function  and  how  these 
functions  interact  in  their  use  of  resources. 

2.  Reliability  and  maintainability  data  for  each  re¬ 
source  identified  in  the  structural  data. 


Essentially,  the  structural  data  relate  resource  failures 
(point  failures)  to  system  failures  for  any  specified  mission 
environment.  These  data  are  typically  available  from  several 
sources : 

1.  Function  descriptions  describe  the  signal  processing 
path  in  terms  of  resources  required  to  perform  each  function 
(Figure  5)  . 

2.  System  and  processing  allocations  describe  how  much 
of  the  system  capacity  (multiplexer ,  signal  processor,  or  data 
processor  throughput)  is  required  to  perform  each  function 
(Table  2). 

3.  System  timing  descriptions  provide  data  on  the  times 
at  which  different  functions  utilize  resources;  i.e.,  whether 
functions  can  be  scheduled  to  use  resources  at  different  times 
(resource  sharing)  or  must  use  different  resources  at  the  same 
time  (Figure  6) . 


1  L-BAND  ANTENNA  CONNECTOR 

2  L-BAND  RECEIVERS 

1  2x3  L-BAND  SWITCH 

2  PREPROCESSORS 

1  SIGNAL  PROCESSOR 

2  HIGH-SPEED  DATA  BUSES 

1  POWER  AND  CONTROL 

UHF  REQUIRES: 

1  LOW -BAND  ANTENNA  SWITCH 

1  LOW- BAND  RECEIVER 

1  2x5  LOW- BAND  SWITCH 

1  PREPROCESSOR 

1  SIGNAL  PROCESSOR 

2  HIGH-SPEED  DATA  BUSES 

1  POWER  AND  CONTROL 

SINCGARS  REQUIRES: 

ALL  UHF  RESOURCES 
1  SECURE  DATA  UNIT  I/O 


Figure  5.  Function  Descriptions  for  an 
Example  Architecture. 


Table  2.  Processing  Allocations  for  an 
Example  Architecture 


Function 

Signal  Processor  „ 
Throughout  (MIPS)3 

GPS 

8.0 

UHF 

1.0 

S INCGARS 

4.0 

Each  signal  processor  has  a  capacity  of 
10  Million  Instructions  Per  Second  (MIPS). 


Low-Band  Receiver  and  Switches 


Can  be  shared  (rapidly  reprogrammed)  between 
UHF  and  SINCGARS 


Preprocessors 


•  Required  continually  by  UHF  and  SINCGARS 
(cannot  be  rapidly  reprogrammed) 

•  Required  at  fixed  times  by  GPS 


Signal  Processors 


•  A  function  assigned  to  one  Digital  LRU  can 
use  the  signal  processor  in  the  other  LRU 
via  the  data  buses 

•  Signal  processors  can  only  be  powered  by 
the  power  supply  in  their  own  LRU;  however, 
they  can  receive  control  data  from  either 
controller 


Power  Supplies,  Buses  and  Controllers 


•  Can  handle  all  functions  simultaneously 


SDU  I/O 


SINCGARS  must  use  the  SDU  in  the  same  LRU 
in  which  it  is  preprocessed  for  control 


reasons 


Figure  6.  Processing  Descriptions  for  an 
Example  Architecture. 


4.  Block  diagrams  show  switching  limitations  that  help 
to  define  the  alternative  signal  processing  paths  that  are 
available  to  perform  each  function  (Figure  7). 
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Figure  7. 


Block  Diagram  for  an  Example  Architecture. 


5.  Software  descriptions  identify  the  fault  recovery 
techniques  used  and  their  implication  in  terms  of  which  faults 
can  be  recovered  from  (Figure  8). 


Figure  8. 


Fault  Recovery  Techniques  for  an 
Example  Architecture. 


•.v.*  V  V 
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Reliability  and  failure  mode  data,  broken  down  to  the 
level  of  resource  failure  rates,  are  generally  available  from 
standard  reliability  program  tasks.  If  data  on  false  alarm 
rates  and  undetected  failure  rates  are  available,  they  can 
also  be  incorporated  in  MIREM.  Maintainability  (MTTR)  esti¬ 
mates  can  also  be  entered. 


3 . 2  Preparing  the  Function  List 

The  first  step  in  preparing  MIREM  data  for  an  archi¬ 
tecture  is  to  list  the  functions  performed  by  the  system  at 
the  operational  or  mission  level.  Functions  are  assigned  se¬ 
quential  numbers,  and  names  of  eight  characters  or  less 
(Figure  9). 

Separate  functions  are  needed  for  each  system  capability 
that  may  be  stated  as  a  separate  requirement  in  a  mission 
environment.  Further  separation  of  functions  (e.g.,  separate 
receive  and  transmit)  may  be  needed  to  simplify  the  description 
of  resource  requirements,  if  these  functions  can  be  allocated 
independently  by  the  system  controller. 


Figure  9.  Function  List  for  the 
Example  Architecture. 


3 . 3  Preparing  the  Resource  List 

All  elements  of  the  system,  including  switches,  control 
hardware,  interconnections  and  external  interfaces,  are  broken 
down  into  resources . 

Each  type  of  resource  is  assigned  a 

1.  Resource  number  (up  to  three  digits). 

2.  Quantity  (the  number  of  resources  of  this  type  in  the 
system) . 


3.  Failure  rate  (failures  per  million  hours). 


4.  Classification  as  a  "resource"  (belonging  to  an  LRM/ 
LRU)  or  an  "interconnection." 

5.  Mean  Time  to  Repair  (MTTR)  (hours). 

6.  Resource  name  of  30  characters  or  less. 


The  resource  list  for  the  example  architecture  is  shown  in 
Figure  10.  The  switch  matrices  are  broken  down  into  their 
input  ports,  based  on  the  assumption  that  loss  of  an  input 
port  is  the  primary  failure  mode.  Data  bus  failures  are  not 
considered  in  this  example. 


ARCHITECTURE  FILE  REPORT 

RESOURCE  LIST 

RESOURCE 

FAILURE  RATE  RESOURCE/ 

MTTR 

RESOURCE 

NUMBER 

QUANTITY 

(X  E-6  HRS.) 

INTERCONNECTION  (HOURS) 

NAME 

1 

10 

RESOURCE 

4.0 

L-BAND  ANTENNA  CONNECTOR 

H.VV 

2 

15 

RESOURCE 

3.5 

L-BAND  RECEIVER 

2 

5 

RESOURCE 

2.0 

2X3  L-BAND  SWITCH  PORTS 

1 

10 

RESOURCE 

2.5 

LOW-BAND  ANTENNA  SWITCH 

2 

95 

RESOURCE 

4.0 

LOW-BAND  RECEIVER 

2 

5 

RESOURCE 

3.0 

2X5  LOW-BAND  SWITCH  PORTS 

5 

300 

RESOURCE 

2.0 

PREPROCESSOR 

2 

100 

RESOURCE 

5.0 

SIGNAL  PROCESSOR 

2 

20 

RESOURCE 

4.5 

POWER  SUPPLY 

2 

20 

RESOURCE 

4.0 

SDU  I/O 

2 

100 

RESOURCE 

6.0 

CONTROLLER 

Figure  10.  Resource  List  for  the 
Example  Architecture. 


Resources  are  defined  as  functional  entities  that: 

1.  Do  not  contain  fault  tolerance;  i.e.,  they  fail  as 
a  unit. 

2.  Are  monitored  and  switched  by  the  system  controller 
as  a  single  unit. 

3.  If  used  by  multiple  functions,  cannot  support  any  of 
these  functions  after  a  failure  occurs. 
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This  definition  sets  the  level  of  detail  at  which  a  MIREM  an¬ 
alysis  should  be  conducted.  A  higher-level  view  of  the  system 
will  not  capture  all  of  the  fault  tolerance  inherent  in  the 
design.  If  a  redundant  structure  is  modeled  as  a  single  re¬ 
source,  the  effect  of  its  fault  tolerance  is  lost.  If  two 
specialized  resources  that  are  used  by  different  functions  are 
treated  as  a  single  resource,  the  ability  of  each  function  to 
tolerate  faults  will  be  understated.  In  practice,  it  may  not 
be  possible  to  break  out  all  resources  according  to  this  defi¬ 
nition.  A  higher-level  analysis  can  provide  useful  insights; 
however,  the  unavailability  of  these  data  should  raise  questions 
as  to  how  well  the  fault  tolerance  issues  have  been  addressed. 

Although  resources  are  defined  as  functional  entities, 
they  often  correspond  to  physical  units.  In  current  avionics 
packaging  technology,  resources  often  correspond  to  Shop  Replace 
able  Units  (SRUs).  In  advanced  modular  packaging,  they  often 
correspond  to  LRMs .  However,  MIREM  is  not  limited  to  these 
physical  levels  of  redundancy.  Redundancy  within  a  module 
or  even  within  a  chip  can  be  modeled  by  defining  resources 
appropriately'  "  ~ 


3 . A  Identifying  Resource  Chains 

The  process  of  identifying  the  fault- tolerant  structure 
of  an  architecture  begins  at  the  top  level  with  resource  chains. 
Chains  can  be  identified  by  examining  the  system  block  diagram; 
parallel  chains  correspond  to  the  highest  level  of  switching 
or  redundancy  in  the  system  (see  Figure  3)  and  series  chains 
contain  all  resources  that  are  not  redundant  at  this  level.  In 
the  example  architecture  (Figure  11),  the  dual  redundant  dig¬ 
ital  LRUs  form  two  chains  in  parallel  because  the  low-band 
functions  can  be  routed  through  either  LRU.  The  fact  that  the 
two  LRUs  are  connected  by  data  buses  does  not  prevent  them 
from  being  parallel  chains  (these  are  treated  in  Section  3.5); 
note  that  functions  can  cross  to  the  other  LRU  for  the  signal 
processor  only.  All  other  resources  (i.e.,  both  receiver  LRUs) 
form  a  single  series  chain.  Although  these  LRUs  contain  redun¬ 
dancy,  they  can  be  modeled  as  a  series  chain  because  they  con¬ 
tain  only  one  level  of  redundancy.  In  general,  a  series  chain 
must  contain  no  more  than  one  level  of  redundancy;  parallel 
chains  are  used  to  model  two  levels  of  redundancy. 


Another  restriction  is  that  MIREM  does  not  allow  more 
than  two  chains  in  parallel.  However,  large  numbers  of  parallel 
paths  can  be  modeled  at  the  lower  level  of  redundancy  in  the 
two- level  MIREM  structure,  the  pool  level.  For  more  redundant 
paths  or  more  levels  of  redundancy,  the  group  feature  of  Sec¬ 
tion  3.6  can  be  used.  The  number  of  series  chains  used  does 


Figure  11.  Resource  Chains  for  the 
Example  Architecture. 


not  affect  the  system-level  results;  however,  several  chains 
may  be  desirable  because  the  reliability  budget  is  presented 
by  chain.  The  criteria  for  identifying  resource  chains  are 
summarized  in  Table  3. 

At  this  point  the  function  descriptions  (Figure  5)  are 
used  to  determine  which  functions  can  be  processed  in  each 
chain.  These  function  numbers  are  listed  for  each  chain  as 
shown  in  Figure  12.  Each  chain  is  assigned  a  number.  One 
entry  is  made  for  each  series  chain  or  parallel  chain  pair 
(for  convenience,  each  entry  will  be  referred  to  as  a  chain 
pair) .  Each  chain  pair  is  assigned  a  name  of  30  characters  or 
less . 


3 . 5  Identifying  Resource  Pools 

The  next,  and  most  complex,  step  in  preparing  the  input 
data  is  to  divide  the  resource  chains  into  pools .  A  pool  con¬ 
sists  of  one  or  more  identical  branches  in  parallel;  each 
branch  contains  one  or  more  resources  ( see  Figure  3).  In  some 
cases  pools  are  easily  identified.  Several  data  processors 
that  are  connected  by  data  buses,  share  processing  loads,  and 


Table  3.  Criteria  for  Identifying  Resource  Chains 


Type  of  Chain 

Criteria 

Parallel 

The  highest-level  switching  points  or  redundancy  in 
the  system  correspond  to  chain  boundaries. 

A  function  may  use  only  one  of  the  parallel  chains 
at  a  time  (but  functions  may  "cross  over"  to  use 
certain  resources  in  another  chain;  see  Section  3.5) 

Only  two  chains  are  allowed  in  parallel 

LRUs  often  correspond  to  chains 

Series 

All  resources  not  in  parallel  chains  form  a  series 
chain 

Functions  must  use  a  series  chain  (no  alternate  path) 

Series  chains  contain  no  more  than  one  level  of  redun¬ 
dancy:  i.e.,  each  parallel  path  in  the  chain  must  be  a 
simple  series  structure,  not  containing  redundancy 

ARCHITECTURE  FILE  REPORT 
CHAIN  LIST 

CHAIN  FUNCTIONS 

CHAIN  PAIR  NAME  NUMBER  REQUIRED 


FRONT  END  1  1.2.3 

DIGITAL  2  1,2.3 

3  2.3 


Figure  12.  Chain  Data  for  the 

Example  Architecture. 


have  fault  recovery  capability  (each  can  resume  any  applica¬ 
tion  program  being  run  on  another  processor)  clearly  form  a 
pool.  A  bank  of  fully  switched  identical  receiver  channels  is 
another  example.  When  pool  boundaries  are  not  obvious,  the 
following  approach  is  recommended. 


J*.  V1-  -.T 


26 


Prepare  a  resource  utilization  worksheet  that  shows  how 
each  set  of  resources  is  utilized  by  each  function.  A  partial 
worksheet  for  the  example  architecture  is  shown  in  Table  4. 
Each  entry  in  the  worksheet  describes  how  a  set  of  resources 
is  used  by  functions,  based  on  the  function  descriptions 
(Figure  5)  and  other  data.  Criteria  for  identifying  these 
entries,  or  candidate  resource  pools,  are  listed  in  Table  5. 
Pool  examples  are  shown  in  Figure  3.  One  additional  criterion 
applies  to  worksheet  entries  (but  not  to  pools)  -  structures 
with  only  one  branch  should  contain  only  one  resource;  these 
resources  are  in  series  with  the  rest  of  the  chain.  The 
structure  is  recorded  in  terms  of  the  number  of  parallel 
branches  and  the  resources  on  each  branch  (if  branches  differ, 
see  Section  6.1).  Make  a  single  entry  for  each  structure, 
listing  the  number  of  branches  required  for  each  function. 
However,  if  different  functions  use  the  same  resources  in 
different  structures,  make  duplicate  entries  for  these  re¬ 
sources  (see  Section  6.1). 

Assign  pool  types  (see  Sections  2.3.2  and  2.3.3)  to  the 
entries  as  shown  in  Table  6.  In  Table  4,  entries  10  and  11 
are  labelled  type  N  because  they  are  used  only  by  the  Global 
Positioning  System  (GPS);  similarly,  entry  24  is  used  only  by 
the  Single-Channel  Ground  and  Airborne  Radio  Subsystem 
(SINCGARS).  Entries  12,  13,  and  23  are  type  N  because  they 
are  used  in  a  noncontending  fashion  (see  Figure  6);  similarly, 
entries  20  and  30  are  type  C  because  they  are  used  in  a  con¬ 
tending  fashion.  Entry  21  and  its  counterpart  in  chain  3  are 
type  S  because  the  signal  processors  share  loads.  Entry  22 
is  type  F  because  a  signal  processor  must  use  the  power  supply 
in  its  own  LRU. 

Map  the  candidate  pool  entries  into  resource  pools  using 
the  following  procedures: 

1.  Entries  in  a  chain  with  the  same  pool  type  (N  or  F), 
the  same  functions,  and  no  redundancy  are  combined  to  form 
one  pool. 

2.  All  other  entries  map  one-to-one  into  pools  (but  see 
Section  6.1  if  multiple  entries  have  been  used  for  the  same 
resources  or  if  type  C  pools  in  parallel  chains  do  not  occur 
in  pairs ) . 


Record  these  pools  on  pool  data  entry  forms  (Appendix  C) 
to  facilitate  on-line  data  entry,  by  conducting  the  following 


Entry 

Pool a 

Number  of 

Number 

Type 

Branches 

Resources 

Functions 

Chain  1  -  Front  End 


Chain  2  -  Digital  A 


20 

C 

21 

S 

22 

F 

23 

N 

24 

N 

Chain  3  -  Digital  B 


L-Band  Ant.  Conn. 

L-Band  Receiver 
2x3  Switch  Port 

Low-Band  Ant.  Switch 

Low-Band  Receiver 
2x5  Switch  Port 


Preprocessor 


Signal  Processor 


Power  Supply 


Controller 


SDU  1/0 


Preprocessor 


GPS ( 1 ) 
GPS ( 2 ) 

UHF(l) 

SINC(l) 

UHF(l) 


GPS (2 ) 
UHF(l) 
SINC(l) 

GPS ( 1 ) 
UHF(l) 
S1NC(1) 

GPS ( 1 ) 
UHF(l) 
SlNC(l) 

GPS ( 1 ) 
UHF(l) 
SINC(l) 

SINC(l) 


UHF(l) 

SINC(l) 


Noncontending,  C  -  Contending,  S  -  Shared,  F  -  Chain-Fail 


Table  5.  Criteria  for  Identifying  Resource  Pools3 


Pool/Structure 

Characteristic 

Criteria 

Branch 

Contains  resources  in  series  (no  redun¬ 
dancy  within  a  branch) 

Each  resource  in  a  branch  can  be  used 
by  the  same  set  of  functions 

Branches  do  not  cross  reconfiguration 
(switching)  points 

Number  of 

Branches 

Each  branch  can  be  used  by  the  same  set 
of  functions 

All  branches  (i.e.,  the  whole  pool/ 
structure)  must  be  in  one  chain 

aThese  criteria  also  apply  to  identifying  entries  in  the 
resource  utilization  worksheet. 


1.  Assign  unique  pool  numbers  to  each  pool  except  for 
type  C  and  S  pairs,  which  must  be  assigned  the  same  number. 

2.  Obtain  the  number  of  the  chain  containing  each  pool 
from  the  resource  utilization  worksheet. 


3. 


Assign  the  LRM/LRU  index, 


as  discussed 


in  Section 


3.6 


4.  Label  the  pool  "active"  if  active  redundancy  is  re¬ 
quired  (or  if  the  pool  has  no  redundancy);  label  it  "standby" 
if  standby  redundancy  is  allowed. 

5.  Look  up  resource  type  numbers  in  the  resource  list. 

6.  Assign  undetected  failure  rates  and  false  alarm  rates 
as  fractions  of  all  the  failures  in  the  pool  (pool  failure 
rates  can  be  determined  by  summing  the  failure  rates  of  re¬ 
sources  in  the  pool  from  the  resource  list). 


7.  Assign  utilization  rates,  as  described  below. 

8.  If  repair  policies  are  being  considered,  assign  the 
minimum  numbers  of  branches  that  must  be  operating  in  order 
for  the  system  to  be  allowed  to  perform  another  mission  with¬ 
out  maintenance. 
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Pool 

Type 


Characteristic 


s 

Entries/pools  occur  in  pairs,  one  on  each 
chain  of  a  parallel  chain  pair 

Pair  of  entries/pools  shares  requirements 
(e.g.,  processors  connected  by  a  data  bus) 

Pair  of  entries/pools  has  the  same  branch 
failure  rate 

Dependent  upon  certain  other  resources  in 
the  chain 

F 

Occur  in  parallel  chain  pairs  with  type  S  pools 

Upon  failure,  would  prevent  all  resources  in 
the  chain,  including  type  S,  from  being  used 

N 

All  entries/pools  that  are  not  type  S  or  F 
and  are  used  only  by  one  function 

Entries/pools  that  are  not  type  S  or  F  and 
are  used  in  a  noncontending  fashion  (see 

Section  2.3.3) 

C 

Entries/pools  that  are  not  type  S  or  F  and 
are  used  in  a  contending  or  timesharing 
fashion  (see  Section  2.3.3)  j 

A  completed  pool  data  entry  form  for  the  example  architecture 
is  shown  in  Figure  13.  Entries  10,  11,  and  12  have  been  com¬ 
bined  to  form  pool  10  because  they  contain  no  redundancy. 
Although  entry  11  has  two  branches,  both  are  required  for  GPS. 
It  may  appear  that  entries  22,  23,  and  24  could  be  combined  to 
form  a  series  structure;  however,  if  they  were  combined,  their 
distinctive  pool  types  and  functions  would  be  lost  (e.g.,  the 
SDU  I/O  would  become  a  critical  failure  for  GPS  and  SINCGARS). 


'igure  13  also  includes  the  utilization  rate  in  each  pool 
for  each  function.  For  most  pools,  the  utilization  rate  is 


Figure  13.  Pool  Data  Entry  Form  for  the  Example  Architecture 


POOt  RESOURCE 


merely  the  number  of  branches  required  by  each  function,  taken 
from  the  resource  utilization  worksheet.  However,  for  time¬ 
sharing  resources  such  as  processors  and  multiplexers,  which 
can  support  several  functions  up  to  some  maximum  capacity,  the 
utilization  rate  is  the  fraction  of  the  capacity  that  is  re¬ 
quired  to  perform  the  function.  The  signal  processors  in 
pool  14  have  a  throughput  capacity  of  10  MIPS.  Since  GPS  re¬ 
quires  eight  MIPS  (Table  2),  its  utilization  is  0.8.  Pool 
pairs  are  required  to  have  the  same  utilization  for  functions 
that  can  use  both  pools. 


This  completes  the  preparation  of  the  structural  data  for 
this  example.  The  pool  and  chain  structure  that  has  been 
created  for  the  example  architecture  is  illustrated  in  Fig¬ 
ure  14.  The  next  section  describes  an  alternate  data  format 
that  can  be  used  for  series -parallel  structures  (i.e.,  when 
there  is  no  contention  between  functions). 


3 . 6  Identifying  Resource  Groups 

Architectures  with  more  than  two  levels  of  redundancy 
will  not  fit  the  pool  and  chain  structure  described  in  Sec¬ 
tions  3.3  and  3.4.  If  they  do  not  exhibit  contention  between 
functions  (i.e.,  there  is  only  one  function  or  all  pools  are 
type  N)  these  architectures  can  usually  be  modeled  as  series- 
parallel  structures;  MIREM  allows  these  structures  to  be  de¬ 
fined  using  groups . 


The  example  structure  in  Figure  15  could  not  be  modeled 
using  parallel  chains  because  it  contains  three  levels  of 
redundancy.  The  figure  illustrates  how  the  structure  is 
represented  by  groups,  with  each  group  containing  pools  or 
other  groups.  The  data  required  for  a  group  are  a  subset  of 
the  data  required  for  a  pool : 

1.  A  unique  group  number;  group  numbers  must  be  between 
1000  and  1999,  whereas  pool  numbers  must  be  from  1  to  999. 

2.  The  chain  number. 

3.  The  LRM/LRU  index. 

4.  The  group  type  (analogous  to  pool  type);  only  type  N 
is  allowed. 


5.  The  number  of  pools  or  groups  contained  in  the  group 


ec  ture . 


the  list  of  pools  and 


6.  The  group  "resources";  i.e., 
groups  contained  in  the  group. 

7.  The  "utilization"  of  the  group  by  each  function; 
i.e.,  the  number  of  "resources"  required. 

The  pool  and  group  data  for  Figure  15,  assuming  only  one  func¬ 
tion,  are  shown  in  Figure  16.  Groups  must  be  ordered  so  that 
all  pools  or  groups  contained  in  a  group  precede  it  in  the 
input  file.  The  last  group  is  assumed  to  represent  the  entire 
chain . 


ARCHITECTURE  FILE  REPORT 
POOL  REPORT 

POOL  MINIMUM  UNDETECTED  FALSE  RESOURCE 

CHAIN  POOL  LRM/LRU  NUMBER  FAILURE  REDUN-  LEVEL  FAILURE  ALARM  RESOURCE  FAILURE  RESOURCE 


NUMBER  NUMBER 

NAME 
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RATE  • 

POOL  TYPE 
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REPAIR 
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RATE  • 
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1  1 1 

LI 

1 
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0 
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0  000 

1 
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12 

LI 

1 
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0 

0 . 000 

0  000 

1 
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13 

LI 

1 
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0 

0 . 000 
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1 
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21 

LI 

2 
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NONCONTENOING 
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0 

0  000 

0  000 

2 
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RES2 

22 

LI 

2 

2000 
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0 

0.000 

0  000 

2 
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RES2 

23 

LI 

2 

2000 

NONCONTENOINC 
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0 

0  000 

0.000 

2 

1000 

RES2 

31 

11 

2 
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NONCONTENOING 
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0 

0.000 

0  000 

3 

1000 

RES3 

41 

LI 

1 

1000 

NONCONTENOING 

ACTIVE 

0 

0.000 

0  000 

4 

1000 

RES4 

51 

LI 

1 

2000 

NONCONTENOING 

ACTIVE 

0 

«  »ee 

0  000 

5 

5 

1000 

1000 

RES5 

RES5 

SYSTEM  FAILURE  RATE  U0W 


(•)  FAILURE  RATE  IN  PER  MILLION  HOURS 


GROUP 

NUMBER 

CHAIN 

NUMBER 

GROUP 

TYPE 

ARCHITECTURE  FILE  REPORT 

SUBGROUP  LISTING  BY  GROUP 

POOL/GROUP  LIST 

1121 

1 

N 

11 .  21  . 

1122 

1 

N 

12.  22. 

1  123 

1 

N 

13.  23. 

1120 

1 

N 

1121.1 122.1123. 

1003 

1 

N 

1120.  31. 

1045 

1 

N 

41 .  51  . 

1000 

1 

N 

1003. 1045. 

Figure  16.  Pool  and  Group  Data  for  Figure  15. 


3 . 7  Preparing  the  LRM/LRU  List 

The  final  step  in  preparing  the  input  data  for  an  archi¬ 
tecture  is  to  divide  the  resource  pools  into  sets  to  be  used 
for  generating  a  reliability  budget  (this  step  is  optional). 
One  useful  partitioning  is  to  divide  the  system  into  removable 
units,  namely  LRUs  or  LRMs .  A  pool  may  contain  several  LRMs 
of  the  same  type;  therefore,  it  is  recommended  that  all  LRMs 
of  the  same  type  be  included  in  one  set.  Consecutive  numbers 
are  assigned  to  the  LRM/LRU  groups,  as  shown  in  Figure  17  for 
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LRM/LRU  List  for  the 
Example  Architecture. 


I 


Figure  17. 


the  example  architecture.  These  LRM/LRU  indexes  are  then 
entered  for  each  pool  on  the  pool  data  entry  form  (Figure  13). 


3 . 8  Using  Reliability  Block  Diagrams 

A  Reliability  Block  Diagram  (RBD)  for  each  function,  which 
relates  to  the  MIREM  structure  as  described  in  Section  2.5, 
can  be  used  in  place  of  function  descriptions  and  block  diagrams 
in  the  MIREM  data  preparation  process.  The  RBD  for  the  Ultra- 
High  Frequency  (UHF)  voice  communication  function  in  the  example 
architecture  is  shown  in  Figure  18.  These  diagrams  can  be 
used  to  fill  out  the  resource  utilization  worksheet.  Simple 
k-of-n  structures  (each  function  requires  a  different  number 
of  branches  k)  and  single  resources  in  series  with  these  struc¬ 
tures  form  the  candidate  pools.  Nested  parallel  structures 
form  parallel  chains  (for  more  than  two  levels  of  nested  paral¬ 
lel  structures  or  more  than  two  parallel  paths  at  the  higher 
level,  resource  groups  must  be  used).  It  should  be  noted, 
however,  that  type  S  and  type  F  resources  cannot  be  exactly 
represented  in  an  RBD.  The  signal  processors  in  Figure  18  are 
actually  dependent  on  the  power  supplies.  This  information 
must  be  obtained  from  other  sources  in  order  to  model  them 
correctly  as  type  S  and  type  F  pools,  respectively.  Additional 
information  on  the  contention  between  functions  is  also  re¬ 
quired  to  determine  pool  type  and  determine  the  total  number 
of  branches  required  in  each  pool. 


4.  PROGRAM  OPERATING  PROCEDURES 


4.1 


Program  Overview 


To  exercise  MIREM  the  user  interacts  with  three  programs 
as  shown  in  Figure  19.  Program  DATAIN  is  used  to  create,  re¬ 
view,  and  modify  the  two  types  of  files  required  to  operate 
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DIRECT  ' 

EDITING 
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ARCHITECTURE 

FILE 
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(COMPUTATION 

PROGRAM) 
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(PLOTTING 
PROGRAM) 


Figure  19. 


MIREM  Program  Overview. 


MIREM.  Program  MIREM  is  used  to  generate  reports  on  the  con¬ 
tents  of  these  files  and  the  model  results,  and  to  create  plot 
files.  Program  MPLOT  is  used  to  display  graphical  results 
stored  in  the  plot  files.  A  direct  editing  option  is  also 
provided  that  allows  the  advanced  user  to  enter  changes  directly 
to  architecture  and  scenario  files  rather  than  through  DATAIN. 

The  programs  are  written  in  FORTRAN  77  and  can  be  operated 
in  a  wide  variety  of  computing  environments.  Program  DATAIN 
operates  interactively  and  is  compatible  with  most  full-screen 
and  scrolling  terminals.  DATAIN  can  also  be  used,  though  less 
quickly,  with  hard-copy  terminals.  Program  MPLOT  can  be  used 
in  a  wide  variety  of  interactive  environments  but  requires  the 
DI3000  graphics  package  and  associated  device  drivers. 

This  chapter  contains  procedures  for  operation  of  programs 
DATAIN  (Section  4.2) ,  MIREM  (Section  4 . 4 )  ,  and  MPLOT  (Sec¬ 
tion  4.5)  once  the  input  data  have  been  prepared  off-line  as 
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described  in  Chapter  3.  The  direct  editing  option  is  explained 
in  Section  4.3.  Certain  limitations  that  apply  to  these  pro¬ 
grams  are  identified  in  Section  4.6,  and  the  use  of  MIREM 
features  is  summarized  in  Section  4.7. 


4 . 2  DATAIN  Program  Operation 

This  section  provides  instructions  for  operating  program 
DATAIN.  Processing  during  a  DATAIN  session  is  done  on  a  series 
of  screens .  Each  screen  defines  a  single  type  of  interaction 
with  the  user.  All  of  the  screens  that  can  be  encountered  in 
using  DATAIN  are  shown  in  Figure  20.  These  screens  will  be 
described  in  the  following  sections. 

4.2.1  Initiating  DATAIN 

Procedures  for  accessing  DATAIN  will  depend  on  the  com¬ 
puter  installation  being  used.  Once  the  user  has  logged  on 
and  has  access  to  the  MIREM  library,  the  DATAIN  program  is 

initiated  by  a  command  such  as  RUN  DATAIN^- .  An  access  message 
is  provided  that  identifies  the  program  configuration  version 
date . 

4.2.2  DATAIN  Keywords 

Following  the  access  message,  the  user  may  obtain  an  ex¬ 
planation  of  DATAIN  keyword  commands  by  entering  HELP .  These 
commands,  which  are  listed  in  Figure  21,  have  the  same  meaning 
when  they  are  entered  at  any  point  in  the  DATAIN  session.  The 
allowable  keywords  at  each  point  are  always  displayed  at  the 
bottom  of  the  screen.  The  HELP,  CONTINUE,  and  QUIT  commands 
are  available  at  any  point  in  the  session.  This  feature  allows 
the  user  to  quickly  terminate  the  program  at  any  time.  After 
the  user  input  QUIT ,  a  termination  screen  is  displayed.  If 
the  user  verifies  the  QUIT  command,  program  DATAIN  is  termin¬ 
ated,  and  any  unsaved  data  inputs  are  discarded. 

Whenever  the  user  is  unsure  about  what  input  is  being 
requested,  HELP  should  be  entered.  A  message  identifying  data 
input  requirements  and  formats  will  then  be  provided.  On  the 
other  hand,  if  the  meaning  of  the  data  elements  in  the  MIREM 
analysis  is  unclear,  enter  EXPLAIN .  An  explanation  of  the 
relevant  MIREM  terminology  will  be  provided. 


throughout  this  chapter,  entries  made  by  the  user  are 
underscored  to  distinguish  them  from  messages  sent  by  the  system 
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Figure  20 


DATAIN  Screen  Flowchart 


The  PAGEn  command  is  used  to  view  different  pages  of  a 
multiscreen  display.  The  entry  PAGE2 ,  for  example,  will  cause 
the  second  page  to  be  displayed. 

4.2.3  File  Maintenance 


From  the  initial  access  or  control  keyword  screen,  the 
entry  CONTINUE  will  bring  the  user  to  the  dialogue  selection 
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Figure  21. 


DATAIN  Control  Keywords. 


menu.  This  screen  controls  the  basic  file  maintenance  activi¬ 
ties  that  can  be  performed  with  DATAIN  (Figure  22): 

1.  Create  an  architecture  file  -  this  file  will  contain 
all  the  reliability  and  structure  data  for  a  given  design. 

2.  Modify  an  architecture  file  that  has  been  created 
previously . 

3.  Create  a  scenario  file  -  this  file  will  describe  a 
mission  scenario  and  contain  run  parameters. 

4.  Modify  a  scenario  file  that  was  created  previously. 


Architecture  and  scenario  file  names  must  be  valid  tile- 
names  on  the  computer  system  being  used.  When  a  scenario  fiLe 
is  selected,  DATAIN  checks  to  see  if  this  file  contains  an 
architecture  file  name.  If  not,  the  user  is  prompted  for  a 
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F igure  22 ■  Overview  of  DATAIN  Dialogue 


file  name, 
entering 


The  file  name  ARCHIN ,  for  example,  is  specified  by 


1=ARCHIN 


No  spaces  are  allowed  in  this  entry.  This  architecture  file 
will  be  used  as  a  source  of  funct  :>ns  for  use  in  constructing 
the  scenario  file.  Because  of  thii  dependence,  an  architecture 
file  should  be  created  before  the  a  sociated  scenario  files  are 
created .  Only  the  function  list  need  be  entered  in  the  archi¬ 
tecture  file.  Note  that  a  scenario  file  can  be  used  with  several 
architecture  files  that  contain  the  same  function  list  by  simply 
changing  the  file  name  in  the  scenario  file. 

Architecture  files  are  saved  by  selecting  index  6  (save) 
in  the  architecture  file  menu  screen.  Scenario  files  are  saved 
by  entering  CONTINUE  from  the  mission  phase  list  screen.  Files 
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cannot  be  deleted  or  overwritten  using  DATAIN.  The  user  must 
terminate  DATAIN  and  use  the  appropriate  system  command  in 
order  to  delete  a  file.  Hence,  to  save  an  updated  version  of 
a  file,  a  new  file  name  must  be  assigned  or,  on  a  VAX  system, 
a  new  version  number  may  be  assigned  (e.g.,  SCENAR.DAT ; 2) . 

4.2.4  Architecture  File  Dialogue 

Upon  selecting  to  create  or  update  an  architecture  file 
from  the  dialogue  selection  screen,  the  user  enters  the  archi¬ 
tecture  file  dialogue.  This  dialogue  is  used  to  enter  the 
architecture  data  prepared  according  to  Chapter  3.  It  consists 
of  three  general  types  of  screens  that  are  displayed,  prompting 
the  user  for  inputs: 

1.  Menu  screen. 

2.  Selection  list  screen. 

3.  Data  entry  screen. 

An  example  of  each  will  be  discussed. 

The  only  menu  screen  is  the  architecture  file  menu  (Fig¬ 
ure  23);  it  is  the  first  screen  encountered  in  the  architecture 
file  dialogue.  This  screen  is  used  to  select  the  type  of  data 
to  be  entered  (functions,  LRMs/LRUs,  resources,  chains  or  pools) 
A  data  type  is  selected  by  entering  its  index  number.  All 
data  types  except  LRMs/LRUs  must  be  entered  before  an  archi¬ 
tecture  file  can  be  analyzed  by  MIREM.  The  sequence  in  which 
data  types  are  entered  should  match  the  dependencies  shown 


in  Figure  23;  e.g.,  functions  should  be  entered  before  chains. 


If  function  data  are  altered  after  the  chain  data  are  entered, 
an  inconsistent  file  might  be  created.  The  user  is  responsible 
for  correcting  these  inconsistencies.  Certain  inconsistencies 
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selection. 

Figure  23 


Architecture  File  Menu  Screen. 
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will  prevent  the  file  from  being  saved.  However,  the  user 
will  not  be  alerted  to  many  of  these  inconsistencies  until  the 
file  is  read  by  program  MIREM.  When  the  user  is  finished 
entering  architecture  data,  the  data  are  saved  by  entering  the 
index  6.  After  a  successful  save,  the  session  will  return  to 
the  dialogue  selection  screen.  The  user  may  also  cancel  the 
architecture  data  that  have  been  entered  by  entering  QUIT. 

An  example  of  a  selection  list  screen  is  the  pool  list 
(Figure  24).  Selection  list  screens  display  a  list  of  data  of 
a  certain  type  (e.g.,  pool  data).  When  a  new  file  is  being 
created,  no  items  will  appear  on  this  initial  list.  The  user 
may  add,  repeat,  change,  or  delete  items  from  this  list.  For 
example,  the  entry 


1=C  2=D  ADD 


will  cause  the  data  for  the  pool  with  index  1  to  be  displayed 
for  the  user  to  change.  The  pool  with  index  2  will  be  marked 
for  deletion.  After  changes  to  pool  1  are  completed,  the  user 
will  be  prompted  to  enter  data  for  a  new  pool  (add  a  pool). 
The  repeat  option  (e.g.,  1=R)  allows  the  user  to  add  a  new 
pool  that  is  identical  to  an  existing  pool.  This  option  is 
particularly  valuable  for  creating  parallel  chains.  Type  C 
and  type  S  pools  can  often  be  repeated  and  only  the  chain  num¬ 
ber  changed.  Commands  must  be  separated  by  a  space  or  a  comma 
Commands  of  the  form  index=value  (e.g. ,  1=C)  may  not  contain 
spaces.  To  record  changes  and  deletions  in  the  data  list  and 
proceed  to  the  next  screen,  enter  CONTINUE.  To  cancel  the 
changes  and  deletions  that  are  displayed  on  the  screen  and 
return  to  the  previous  screen,  enter  BACK.  Items  that  have 
been  added  to  the  list  are  not  removed  by  the  BACK  command. 


POOL  LIST 


Pool  Chain  No.  of  Resource 

Index  No.  No.  Lrm/Lru  Name  Pool  Type  Branches  Numbers  A/S  C/R/D 


1 •  1  1  LRU1  Noncontending  11  A 

Please  enter  the  command:  indexrvalue,  i ndex=va 1 ue ,  .  . . 

(values  are  'c'  for  Change,  ’r1  for  Repeat,  and  'd1  for  Delete) 

Or  enter  a  command :< H> ELP ,  <E>XPLAIN,  <C>ONTINUE,  < A> DD ,  <B>ACK,  <Q>UIT 

1-R 
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One  example  of  a  data  entry  screen  is  pool  data  entry 
(Figure  25).  Here  the  format  index=value  is  used  to  enter  or 
change  parameter  values.  For  example,  the  entry 


3= ' L-BAND  RF’  5=2 


changes  the  LRM/LRU  name  to  L-BAND  RF  and  the  number  of  branches 
to  2.  Names  that  contain  spaces  must  be  enclosed  in  single 
quotes.  Again,  commands  of  the  form  index=value  may  not  con¬ 
tain  spaces  between  the  index  and  the  value.  When  a  new  pool 
is  being  created,  default  values  will  appear  for  some  of  the 
parameters;  if  these  values  are  correct,  the  parameter  need  not 
be  entered.  To  proceed  to  the  next  screen,  enter  CONTINUE. 

To  cancel  the  changes  that  were  made  on  this  screen  and  return 
to  the  previous  screen,  enter  BACK.  In  cases  where  several 
data  entry  screens  are  visited  in  sequence  before  looping  back 
to  a  selection  list  screen  (chains,  pools  and  missions  phases  - 
see  Figure  20),  the  BACK  command  cancels  the  changes  made  on 
all  the  data  entry  screens.  Changes  are  recorded  only  when 
CONTINUE  is  typed  to  return  to  the  selection  list  screen. 


POOL 

DATA  ENTRY 

Index 

Parameter 

Current 

Value 

1  . 

Pool  Number 

1 

2  . 

Chain  Number 

i  . 
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Pool  Data  Entry  Screen. 


Another  form  of  data  entry  screen  is  illustrated  by  the 
functions  in  chain  screen  (Figure  26).  In  this  type  of  screen 
a  list  of  available  items  is  displayed.  A  subset  of  these 
items  is  then  specified  by  the  user.  The  screen  in  Figure  26 


FUNCTIONS  IN  CHAIN  NUMBER  3 


Index  Function 


*1.  FUNC1 
*2.  FCN2 
*3.  FCN3 

4 .  FCN4 

5 .  FCN5 

NOTE:  The  asterisk  ('*')  indicates  functions  selected. 

Please  enter  the  command:  index  to  select  or  -index  to  delete. 

Or  enter  a  command :<H>ELP,  <E>XPLAIN,  <C>ONTINUE,  <B>ACK,  «2>UIT 


Figure  26.  Functions  in  Chain  Screen. 


is  used  to  specify  the  functions  that  can  be  processed  in  chain 
number  3 .  The  entry 

-2  4 


deletes  the  function  with  index  2  from  the  chain  and  adds  the 
function  with  index  4.  The  selected  items  are  indicated  by  an 
asterisk  before  the  index. 

4.2.5  Scenario  File  Dialogue 

Upon  selecting  to  create  or  update  a  scenario  file  from 
the  dialogue  selection  screen,  the  user  enters  the  scenario 
file  dialogue.  This  dialogue  is  used  to  enter: 

1.  A  mission  scenario 

2.  Run  parameters. 


The  user  may  wish  to  maintain  one  scenario  file  for  each  mis¬ 
sion  scenario.  When  a  particular  run  is  needed,  the  run  param¬ 
eters  (including  the  architecture  file  name)  are  entered  into 
the  scenario  file  containing  the  desired  mission,  and  program 
MIREM  is  initiated. 

The  scenario  file  dialogue  contains  the  same  general  types 
of  screens  as  are  described  in  Section  4.2.4.  The  first  screen 
encountered  is  a  data  entry  screen  used  to  enter  a  run  iden¬ 
tifier.  Again  the  format  index=value  is  used;  e.g.,  1= ' SCENARIO 
FILE  EDITING  TEST2 ' .  If  the  run  identifier  contains  blanks, 
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it  must  be  enclosed  in  single  quotes.  In  the  computation  and 
plot  selection  menus,  multiple  options  can  be  selected.  The 
output  generated  by  each  selection  is  described  in  Chapter  5. 
Run  parameters  entered  in  the  basic  scenario  file  parameters 
screen  are  listed  in  Table  7. 

The  mission  scenario  is  entered  using  the  mission  phase 
list  screen  which  employs  the  same  conventions  as  described  in 
Section  4.2.4.  When  all  mission  phase  data  have  been  entered, 
the  entry  CONTINUE  is  used  to  save  the  data  from  this  dialogue 
in  the  scenario  file  and  return  to  the  dialogue  selection  screen 


Table  7.  Scenario  File  Run  Parameters 


Name 

Description 

Processing  Option 

'FULL'  gives  exact  results  for  single¬ 
phase  missions  and  may  cause  an  abort 
for  some  architectures;  'QUICK'  gives 
approximate  results  for  parallel 
chains  but  guarantees  the  computa¬ 
tion  will  be  completed  relatively 
quickly 

Print  Architecture 
File  Report 

Allows  the  user  to  verify  all  the 
model  inputs  that  went  into  the  run 

Print  Intermediate 
Results 

Generates  more  detailed  cutput  as 
described  in  Chapter  5 

Functions  Required 
Simultaneously 

Determines  whether  functions  required 
within  a  phase  compete  for  system 
resources.  For  most  scenarios  the 
appropriate  value  is  'YES' 

Failure  Rate 

Scale  Factor 

All  resource  failure  rates  are 
multiplied  by  this  factor 

Scheduled 

Maintenance 

The  scheduled  maintenance  interval 
(hours)  used  in  repair  analysis  must 
be  at  least  as  large  as  the  first 
total  operating  time 

Repair  Sequence 

'Series':  multiple  repairs  are  per¬ 

formed  sequentially  (one  maintenance 
crew);  'Parallel':  multiple  repairs 
are  performed  simultaneously  (un¬ 
limited  maintenance  crews) 

The  advanced  user  may  elect  to  modify  architecture  and 
scenario  files  by  using  a  system  editor  rather  than  through 
DATAIN.  To  support  this  direct  editing  option,  readable  formats 
have  been  adopted  for  these  files  and  are  defined  in  this  section 

4. 3.1  Architecture  File  Format 

Figure  27  shows  the  format  of  the  architecture  file.  The 
architecture  file  generated  by  program  DATAIN  is  shown  in 
Figure  28.  The  file  must  contain  at  least  one  card  of  each 
type  except  LRU,  GROUP,  GROUP  RESOURCE,  GROUP  UTILIZATION,  and 
comments.  The  order  restrictions  are: 

1.  Chain  function  cards  must  be  immediately  after  the 
chain  card  to  which  they  refer. 

2.  Pool  resource  and  pool  utilization  cards  must  be 
immediately  after  the  pool  card  to  which  they  refer,  in 
that  order. 


JUNCTION 

-LRU 

.RESOURCE 

_£HAIN 

.CHAIN  FUNCTION 

POOL 


fcn-name-llst 

Iru-name-list 

r-number,  r-qty,  f.r.,  r/i,  mttr,  r-name 
0 


p-chn-numbar, 

p-chnnumbor 
s-chn-numbar 


s-chn-numbar 
,  fcn-list 


p  number, 


p-chn  numbar 
s-chn-numbar 


0 

Iru  index 


.POOL  RESOURCE  p-number.  r-list 

_POOL  UTILIZATION  p-number,  u-list 

*  comment 

J3ROUP  g-number.  p-chn-number. 


0 

I  Iru-index 


p  type,  no  branches,  a/s.  undetected  f.r., 
false  alarms,  repair  level 


g  type,  no-subgr 


_QROUP  RESOURCE  g-number.  subgr-list 
GROUP  UTILIZATION  g  number,  u  list 


»  FUNCTION  CARO:  LIST  OF  FUNCTION  NAMES 


FUNCTION  'GPS  ’  ' UHF  1  ’SINC 


•  LRM/LRU  CARO:  LIST  OF  LRM/LRU  NAMES 


LRU  'FRONTEND  ’  ’OIGITALA  '  'DIGITALB 


•  RESOURCE  CARO:  RESOURCE  NO.,  QUANTITY,  FAILURE  RATE,  TYPE.  MTTR ,  NAME* 

•  NOTE:  FAILURE  RATE  IS  IN  PER  MILLION  HOURS  • 


RESOURCE  1  1  10  R  4.0  L-BAND  ANTENNA  CONNECTOR 

RESOURCE  2  2  15  R  3.5  L-BAND  RECEIVER 

RESOURCE  3  2  5R2.02X3  L-BAND  SWITCH  PORTS 

RESOURCE  4  1  10  R  2.5  LOW-BAND  ANTENNA  SWITCH 

RESOURCE  5  2  95  R  4 . 0  LOW-BAND  RECEIVER 

RESOURCE  6  2  5  R  3.0  2  X  5  LOW-BAND  SWITCH  PORTS 

RESOURCE  7  5  300  R  2.0  PREPROCESSOR 

RESOURCE  8  2  100  R  5  0  SIGNAL  PROCESSOR 

RESOURCE  9  2  20  R  4.5  POWER  SUPPLY 

RESOURCE  10  2  20  R  4.0  SOU  I/O 

RESOURCE  11  2  100  R  6.0  CONTROLLER 


•  CHAIN  CARD.  PRIMARY  CHAIN  NUMBER.  PARALLEL  CHAIN  NUMBER.  CHAIN  NAME 

•  NOTE:  PARALLEL  CHAIN  NUMBER  IS  0  WHEN  CHAIN  IS  SERIES  CHAIN 


•  CHAIN  FUNCTION  CARO.  CHAIN  NUMBER.  LIST  OF  FUNCTION  INDICES 


CHAIN  10  FRONT  END 

CHAIN  FUNCTION  1  123 

CHAIN  2  3  DIGITAL 

CHAIN  FUNCTION  2  123 

CHAIN  FUNCTION  3  23 


•  POOL  CARD:  POOL  NUMBER,  CHAIN  NO,  LRU  INDEX,  POOL  TYPE,  BRANCHES. 

•  ACTIVE/STANDBY.  UNDETECTED  FAILURES,  FALSE  ALARMS.  MIN  REPAIR  LEVEL 

•  NOTE-  FOR  POOL  TYPE.  'N'  IS  NONCONTENDING,  ’C’  IS  CONTENDING, 

•  ’S'  IS  SHARED.  AND  *F*  IS  CHAIN-FAIL 


•  POOL  RESOURCE  CARD:  POOL  NUMBER,  LIST  OF  RESOURCE  NUMBERS 


*  POOL  UTILIZATION  CARD:  POOL  NUMBER,  LIST  OF  FUNCTION  UTILIZATIONS 
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(Concluded) . 


3.  Group  resource  and  group  utilization  cards  must  be 
immediately  after  the  group  card  to  which  they  refer,  in  that 
order . 

4.  Groups  must  be  ordered  so  that  all  pools  and  groups 
in  the  subgroup  list  occur  before  that  group. 

5.  All  function  cards  should  precede  all  chain  cards. 

6.  All  function,  LRU,  resource,  and  chain  cards  should 
precede  all  pool  cards. 


These  cards  contain  the  following  elements: 

1.  fcn-name-list  -  a  list  of  8-character  function  names. 
Names  containing  blanks  should  be  enclosed  in  single  quotes. 
Names  should  be  separated  by  blanks  or  commas.  The  order  of  a 
function  in  the  list  determines  its  index;  e.g.,  the  first 
function  has  a  index  of  1. 


2.  lru-name-list  -  a  list  of  16-character  LRU  names. 
See  fcn-name-list. 


3.  r-number  -  resource  type  number;  a  unique  integer 
from  1  to  999. 

4.  r-qty  -  the  number  of  resources  of  a  given  type  in 
the  system;  an  integer  from  1  to  99. 

5.  f . r .  -  failure  rate  in  failures  per  million  hours;  an 
integer  from  1  to  9999. 

6.  r/'i  -  each  resource  type  is  a  RESOURCE  or  INTERCON¬ 
NECTION. 

7.  mttr  -  mean  time  to  repair  this  resource  type,  in 
hours. 

8.  r-name  -  a  30-character  resource  name;  not  enclosed 
in  single  quotes. 

9.  p-chn- number  -  primary  chain  number;  an  integer  from 
1  to  99  (must  be  unique  on  chain  cards). 

10.  s-chn-number  -  secondary  chain  number;  an  integer 
from  1  to  99  (must  be  unique  and  distinct  from  primary  chain 
numbers  on  chain  cards). 

11.  c-name  -  a  30-character  chain  pair  name;  not  enclosed 
in  single  quotes. 

12.  fcn-list  -  a  list  of  function  indexes;  each  index  is 
an  integer  from  1  to  the  number  of  functions  listed  on  func¬ 
tion  cards. 

13.  p- number  -  pool  number;  an  integer  from  1  to  999, 
unique  except  that  two  occurrences  are  allowed  if  the  chain 
numbers  listed  on  their  pool  cards  form  a  parallel  chain  pair. 

14.  lru- index  -  LRU  index;  an  integer  from  1  to  the  num¬ 
ber  of  LRUs  listed  on  LRU  cards. 

p- type  -  pool  type;  N,  C,  S,  or  F. 

16.  no . -branches  -  number  of  branches;  an  integer  from  1 
to  99 . 

17.  a/s  -  each  pool  uses  ACTIVE  or  STANDBY  redundancy. 

18.  undetected- f . r .  -  the  fraction  of  failures  in  a  pool 
that  are  undetected ;  from  0  to  1 . 


19.  false-alarms  -  the  ratio  of  false  alarms  to  failures 
in  a  pool;  nonnegative. 

20.  repair- level  -  the  minimum  number  of  branches  that 
must  be  functioning  in  a  pool  for  the  system  to  be  allowed  to 
perform  another  mission  without  maintenance;  an  integer  from  0 
to  no . -branches . 

21.  r-list  -  list  of  r-numbers;  separated  by  blanks  or 
commas . 

22.  u-list  -  list  of  utilization  rates.  Sequence  in  the 
list  identifies  the  function  index  to  which  the  rate  applies. 
Length  of  the  list  should  equal  the  number  of  functions  listed 
on  function  cards.  Each  rate  is  a  real  number  between  0  and 
no. -branches  (for  pools)  or  the  length  of  the  subgr-list  (for 
groups) . 

23.  g-number  -  group  number;  a  unique  integer  from  1000 
to  1999. 

24.  g-type  -  group  type;  must  be  'N. 1 

25.  no . -subgr  -  number  of  subgroups;  not  used,  set  to  1. 

26.  subgr-list  -  list  of  r-numbers  and  g-numbers;  separ¬ 
ated  by  blanks  or  commas,  no  repetition  allowed. 


4.3.2  Scenario  File  Format 


Figure  29  shows  the  format  of  the  scenario  file.  A  sce¬ 
nario  file  generated  by  program  DATAIN  is  shown  in  Figure  30. 
The  file  should  contain  at  least  one  card  of  each  type  except 
phase,  phase  function,  and  comment  cards.  Phase  function  cards 
must  be  immediately  after  the  phase  card  to  which  they  refer. 
The  sequence  of  the  phase  cards  determines  the  order  of  phases 
in  the  mission.  These  cards  contain  the  following  elements: 

1.  runid  -  a  72-character  name  identifying  the  run. 

2.  filename  -  architecture  file  name;  a  legal  system 
file  name. 

3.  s- factor  -  failure  rate  scale  factor;  a  positive  real 
number . 

4.  total -operating- time -list  -  a  list  of  positive  real 
numters  separated  by  blanks,  in  units  of  hours. 
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A  36406 


RUNID 

HARDWARE 

COMPUTE 

PLOT 

QUICK 

runid 

Manama 

1MCSP]  (PHASE-BY-PHASE)  [MTBCF)  IMTBFF]  ILRUI  [REPAIR!  [BIT]  [FULLBIT1 

(MCSP!  (PHASE-BY-PHASE!  [MTBCF]  [MTBFF]  [LRU!  [REPAIR! 

YES 

NO 

HARDWARE  1  j  YES 

PRINT 

INTERMEDIATE  j  j  NO 

SIMULTANEOUS 

YES 

NO  { 

SCALE 

•  factor 

TIME 

total-oparating-tima-list 

TMAINTENANCE 

scheduled- maintenance-interval 

|  SERIES  | 

REPSEQUENCE 

|  PARALLEL  j 

PHASE 

ph-index.  ph-duratfon.  ph-nama 

PHASE  FUNCTION 

ph-indax.  fcn-liat 

• 

comment 

Figure  29.  Scenario  File  Format. 


RUNID  TEST1 


COMPUTE 

MCSP  PHASE  LRU  MTBCF  MTBFF  REPAIR 

BIT  FULLBIT 

►  •  *  *  • 

PLOT 

MCSP  MTBCF  PHASE  REPAIR 

OUICK 

YES 

PRINT  HARDWARE 

YES 

PRINT  INTERMEDIATE  NO 

SIMULTANEOUS 

YES 

SCALE 

1 ,0 

TIME 

3.0  HOURS 

TMAINTENANCE 

100.  HOURS 

REPSEQUENCE 

PARALLEL 

•  PHASE  CARD  PHASE  INDEX.  TIME-OF-PHASE  (HOURS),  PHASE  NAME 

• 

•  PHASE  FUNCTION 

CARD:  PHASE  INDEX,  LIST  OF  FUNCTION 

INDICES 

* 

PHASE 

1  1.50  PHASE  1 

PHASE  FUNCTION 

1  2 

PHASE 

2  1.00  PHASE  2 

PHASE  FUNCTION 

2  1  3 

PHASE 

3  0.50  PHASE  3 

PHASE  FUNCTION 

3  2 

5.  scheduled -maintenance -interval  -  real  number  greater 
than  or  equal  to  the  first  total-operating- time ,  in  units  of 
hours . 

6.  ph- index  -  phase  index;  an  integer  from  1  to  the  num¬ 
ber  of  phases,  equal  to  the  sequence  of  this  phase  card  among 
all  the  phase  cards. 

7.  ph-duration  -  phase  duration;  a  positive  real  number, 
in  units  of  hours. 

8.  phase-name  -  a  30-character  phase  name. 

9.  fcn-list  -  list  of  function  indices,  separated  by 
blanks  or  commas;  integers  from  1  to  the  number  of  functions, 
unique  within  a  phase. 


4 . 4  MI REM  Program  Operation 

Once  architecture  and  scenario  files  have  been  created 
using  program  DATAIN ,  program  MIREM  is  used  to  compute  model 
results  and  to  generate  reports  desplaying  the  data  in  these 
files.  Procedures  for  accessing  MIREM  will  depend  on  the  com 
puter  installation  being  used.  For  a  VAX  11/780  system,  the 
MIREM  program  may  be  run  by  entering: 


0MIREM  scenario- filename 


where  scenario- filename  is  the  system  name  of  a  valid  scenario 
file.  Note  that  the  scenario- filename  may  be  left  out,  in  which 
case  the  interactive  user  will  be  prompted  for  the  scenario- 
filename  . 

Generally,  the  scenario  file  contains  a  hardware  card 
with  the  hardware  file  name.  In  this  case  the  user  does  not 
need  to  worry  about  the  hardware  file.  However,  if  the  user 
uses  the  direct  editing  option  (Section  4.3)  and  creates  a 
scenario  file  without  a  hardware  card,  then  the  user  should 
enter: 


@MIREM  scenario- f i lename  hardware- filename 


where  hardware- f i lename  is  the  system  name  of  a  valid  hardware 
file. 
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The  results  are  written  to  a  file  which  by  default  is 
named  MIREM. OUT  on  a  VAX  system.  This  file  may  be  examined 
on-line.  On  most  systems  it  will  be  printed  automatically. 
The  output  may  be  written  to  a  different  file  by  entering: 

0MIREM  scenario-filename  hardware-filename  output-filename  plot-filename 

where  output- filename  specifies  a  file  to  which  to  write  output 
reports  and  plot- filename  specifies  a  file  to  which  to  write 
the  plot  data. 


MPLOT  Program  Operation 


When  program  MIREM  has  been  run  on  a  scenario  file  contain¬ 
ing  a  plot  card,  and  a  plot  file  has  been  generated,  program 
MPLOT  is  used  to  generate  plots.  Use  of  MPLOT  requires  linking 
with  the  DI3000  graphics  package  and  associated  device  drivers. 
The  MPLOT  program  is  run,  on  a  VAX  11/780  system,  by  entering 


RUN  MPLOT 


The  user  will  then  be  prompted  for  the  plot  file  name  and  the 
device  number.  For  most  users,  the  device  number  will  be  1. 
Procedures  for  directing  the  plot  output  to  a  graphics  printer 
will  depend  on  the  computer  installation  being  used. 


4 . 6  Limitations 

Certain  limits  have  been  set  on  the  size  of  model  that 
can  be  analyzed  by  MIREM.  These  limits  are  shown  in  Table  8. 
They  result  in  virtual  memory  requirements  of  205,000  bytes  for 
program  MIREM,  275,000  bytes  for  program  DATAIN ,  and  60,000  bytes 
for  program  MPLOT  on  a  VAX  11/780.  Also,  a  disk  space  of 

3.6  megabytes  should  be  allocated  for  the  combined  software. 


Three  additional  restrictions  have  been  imposed  to  prevent 
extremely  long  run  times.  The  worst-case  run  time  grows  ex¬ 
ponentially  with  the  number  of  functions  listed  within  a  mis¬ 
sion  that  appear  in  the  function  list  for  both  chains  in  a 
parallel  chain  pair.  The  number  of  functions  in  this  category 
is  limited  to  eight. 


When  the  full  processing  option  is  selected,  MIREM  iter¬ 
ates  over  "substantially  different"  function  allocations  to 
parallel  chains  (see  Appendix  A).  The  number  of  allocations 
is  limited  to  15. 
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Table  8. 


MIREH  Size  Limitations 


■  1 

Maximum 

Category 

Number 

Functions 
LRMs/LRUs 
Resources 
Chain  pairs 
Pools  and  groups 
Mission  phases 
Branches  per  pool 
Resources  per  branch 
Subgroups  per  group 
Functions  per  phase 


Maximum 
Length 
(Characters ) 


Function  name 

8 

LRM/LRU  name 

16 

Resource  name 

30 

Chain  pair  name 

30 

Mission  phase  name 

30 

Run  identifier  name 

72 

The  run  time  for  MTBCF  calculations  is  roughly  propor¬ 
tional  to  the  number  of  integration  time  steps.  For  typical 
inputs,  the  integration  routine  stops  after  20  to  30  steps. 
However,  it  is  conceivable  that  for  some  input  data  the  routine 
would  continue  for  many  more  steps.  The  number  of  steps  is 
limited  to  50.  If  this  limit  is  reached,  a  warning  message 
will  be  printed,  and  the  accuracy  of  the  MTBCF  result  is  suspect 

4 . 7  Compatibility  of  Features 

Not  all  of  the  features  of  this  version  of  MIREM  can  be 
used  at  the  same  time.  The  co-vputational  approaches  used  to 
obtain  some  of  the  results  in  this  version  preclude  the  con¬ 
sideration  of  some  of  MIREM' s  other  features.  These  limita¬ 
tions  are  summarized  in  Table  9.  In  some  cases,  a  computation 
cannot  be  performed  at  all;  MIREM  will  abort  the  run  or,  at 
best,  skip  the  computation.  These  combinations  (X)  should  be 


Table  9.  Compatibility  of  Features 


Neglected;  HIREH  will  neglect  feature  B  when  Feature 
is  present  or  when  computing  this  output  option 


avoided.  In  other  cases,  MIREM  neglects  a  feature  (feature  B) 
that  would  affect  the  result.  The  user  should  be  aware  that 
some  of  the  input  data  is  thus  being  neglected  and  should  exer¬ 
cise  caution  in  comparing  reliability  results  from  different 
output  options,  since  different  features  may  have  been  neglected. 


5.  SAMPLE  STUDIES 


5 . 1  Mission  Effectiveness  Analysis 


MIREM  can  be  used  to  evaluate  reliability  against  a  spe¬ 
cific  mission  scenario  by  using  the  MCSP ,  phase-by-phase,  or 
BIT  output  options.  When  conducting  any  analysis,  it  is  advis¬ 
able  to  obtain  architecture  and  scenario  file  reports  so  that 
all  of  the  model  inputs  are  known.  Figure  31  shows  the  archi¬ 
tecture  file  report  for  the  example  architecture  introduced  in 
Chapter  3;  portions  of  the  report  shown  in  Chapter  3  are  not 
repeated  here.  Figure  32  shows  a  scenario  file  report.  The 
mission  consists  of  three  phases,  with  a  total  duration  of  3.0 
hours.  During  phases  one  and  three,  only  UHF  (function  2)  is 
required.  During  phase  two,  GPS  and  SINCGARS  are  required 
simultaneously. 

The  MCSP  and  pool  budget  results  are  shown  in  Figure  33. 
Contributions  to  MCSP  are  broken  down  by  chain  pair  and  by 
pool.  For  parallel  chain  pairs,  the  manner  in  which  MCSP  is 
computed  does  not  allow  visibility  into  individual  pools;  in¬ 
stead,  the  MCSP  for  each  type  of  pool  is  given.  It  may  be 
possible  to  perform  all  the  functions  on  one  parallel  chain 
even  if  the  other  chain  is  down  (a  type  F  pool  failure).  The 
additional  MCSP  achieved  because  of  this  capability  is  listed 
for  the  primary  and  secondary  chain  in  the  pair.  In  this  ex¬ 
ample,  neither  chain  can  support  the  entire  mission,  and  the 
additional  MCSP  is  zero.  The  immediate  repair  MTBCF  of 
2500  hours  is  calculated  from  MCSP,  assuming  that  the  system 
is  fully  repaired  after  each  mission  (mission  length  is  taken 
from  the  total  operating  time  input).  This  number  will  always 
be  larger  than  the  deferred  repair  MTBCF  described  in  Section  5.2. 

The  equations  used  for  the  MCSP  and  pool  budget  output 
contain  the  approximation  that  each  individual  phase  must  be 
performed  at  the  end  of  the  mission  rather  than  in  sequence. 

This  "phase  approximation"  generates  pessimistic  MCSP  results 
if  the  final  mission  phases  are  less  demanding  than  previous 
phases.  It  should  be  noted  that  logistics/sustainability 
measures,  such  as  MTBCF,  are  not  affected  by  this  approxima¬ 
tion  because  they  address  end-of -mission  or  multiple-mission 
status.  An  alternative  computational  approach  that  avoids 
this  approximation  is  used  for  the  phase -by- phase  MCSP  output. 


ARCHITECTURE  PILE  REPORT 


POOL  REPORT 

POOL  MINIMUM  UNDETECTED  FALSE  RESOURCE 

CHAIN  POOL  LRM/LRU  NLfcfiER  FAILURE  REOUN-  LEVEL  FAILURE  ALARM  RESOURCE  FAILURE  RESOURCE 


NUMBER 

NUMBER 

NAME 

BRANCHES 

RATE  • 

POOL  TYPE 

DANCY 

REPAIR 

RATE 

RATE 

NUMBER 

RATE  • 

NAME 

1 

’0 

FRONT ENO 

1 

50 

NONCONTENOING 

ACTIVE 

1 

0  100 

0  050 

t 

10 

L-Bano  antenna  c 

2 

15 

L-BanD  RECEIVER 

2 

15 

L-8AND  RECEIVER 

3 

5 

2X3  L-BANO  S»l 

3 

5 

2X3  L-BANO  SRI 

1 1 

FRONT END 

1 

10 

NONCONTENOING 

ACTIVE 

1 

0  005 

0  001 

4 

10 

LOW-BAND  ANTENNA 

12 

FRONT ENO 

2 

200 

NONCONTENDING 

STANO0Y 

1 

0  020 

0  010 

5 

95 

LOW-8 AND  RECEIVE 

6 

5 

2X5  L0W-8AN0  S 

2 

13 

D1C1TALA 

3 

900 

CONTENDING 

ACTIVE 

2 

0  010 

0  010 

7 

300 

PREPROCESSOR 

14 

digitala 

i 

100 

SHARED 

ACTIVE 

1 

0  020 

0  005 

6 

100 

signal  processor 

15 

dicitala 

1 

20 

CHAIN-FA] L 

ACTIVE 

1 

0  000 

0  010 

9 

20 

POWER  SUPPLY 

16 

oigitala 

1 

20 

NONCONTENOING 

ACTIVE 

1 

0  010 

0  005 

10 

20 

SOU  I/O 

17 

DIGITALA 

1 

100 

NONCONTENOING 

ACTIVE 

i 

0  050 

0  020 

1 1 

100 

controller 

3 

13 

OIGITALB 

2 

600 

CONTENDING 

ACTIVE 

2 

0  010 

0  010 

7 

300 

PREPROCESSOR 

14 

OIGITALB 

1 

100 

SHARED 

ACTIVE 

1 

0  020 

0  005 

8 

100 

SIGNAL  PROCESSOR 

15 

OIGITALB 

1 

20 

CHAIN-FAIL 

ACTIVE 

1 

0  000 

0  010 

9 

20 

POWER  SUPPLY 

16 

OIGITALB 

1 

20 

NONCONTENOING 

ACTIVE 

1 

0  010 

0  005 

10 

20 

SOU  I/O 

17 

OIGITALB 

1 

100 

NONCONTENOING 

ACTIVE 

1 

0  050 

0  020 

i  1 

100 

CONTROLLER 

SYSTEM  FAILURE  RATE  2240 


(•)  FAILURE  RATE  IN  PER  MILLION  HOURS 


CHAIN 

POOL 

ARCHITECTURE  FILE  REPORT 

FUNCTION  UTILIZATION  BY  POOL 

FUNCTION 

NUMBER 

NUMBER 

GPS 

UHF 

SINC 

1 

10 

1  00 

0.00 

0.00 

1  1 

0.90 

1 .00 

1  .00 

12 

9*0 

1  .00 

1.00 

2 

13 

2  00 

1.00 

1  .00 

14 

0.80 

0.10 

0.40 

15 

1 .00 

1  00 

1 .00 

16 

0.00 

0.00 

1 .00 

17 

1  00 

1  00 

1  00 

3 

13 

2  00 

1  00 

1  00 

14 

0  80 

0. 10 

0.40 

15 

1  .  00 

1  00 

1  00 

16 

0  00 

0  00 

1 . 00 

1  7 

1 .00 

1  .00 

1 .00 

Figure  31. 


Architecture  File  Report  for  the 
Example  Architecture. 


This  output  gives  an  upper  and  lower  bound  for  the  probability 
of  successfully  completing  each  mission  phase,  culminating  in 
MCSP  for  the  entire  mission  (Figure  34).  For  this  example, 
phase  three  is  less  demanding  than  phase  two,  and  the  phase 
approximation  MCSP  (0.9988)  is  actually  below  the  lower  bound 
MCSP  (0.9989).  The  true  MCSP  lies  between  the  lower  and  upper 


SCENARIO  FILE  REPORT 


COMPUTATION/PLOT  SELECTIONS: 

1.  MCSP  ANO  POOL/CHAIN  BUDGET;  IMMEDIATE  REPAIR  MTBCF  (PLOT) 

2.  PHASE-8Y-PHASE  MCSP  (PLOT) 

3  DEFERRED  REPAIR  MTBCF  (PLOT) 

4.  MTBFF  -  MEAN  TIME  BETWEEN  FUNCTION  FAILURES  (NO  PLOT) 

5.  LRM/LRU  BUDGET  (NO  PLOT) 

6  REPAIR  POLICY  (PLOT) 

7.  TESTABILITY  FACTORS  -  BIT  OPTION  (NO  PLOT) 

8.  TESTABILITY  FACTORS  -  BIT  MTBCF  OPTION  (NO  PLOT) 

NOTES : 

MCSP  -  MISSION  COMPLETION  SUCCESS  PROBABILITY 
MTBCF  -  MEAN  TIME  BETWEEN  CRITICAL  FAILURES 


BASIC  SCENARIO  FILE  PARAMETERS: 


1 . 

PROCESSING  OPTIONS: 

QUICK 

2. 

PRINT  HARDWARE  FILE  REPORT?: 

YES 

3. 

PRINT  INTERMEDIATE  RESULTS?: 

NO 

4. 

FUNCTIONS  REQUIRED  SIMULTANEOUSLY? 

YES 

5. 

FAILURE  RATE  SCALE  FACTOR: 

1 .0 

6. 

TOTAL  OPERATING  TIME  (HOURS): 

300 

7. 

REPAIR  SEQUENCE  (MULTIPLES): 

PARALLEL 

8. 

SCHEDULED  MAINTENANCE  INTERVAL: 

100.0 

MISSION  PHASE  LIST 


INDEX 

PHASE 

NAME 

LENGTH 

(HOURS) 

CRITICAL 

FUNCTIONS 

1  . 

PHASE 

1 

1 .50 

2 

2. 

PHASE 

2 

1 .00 

1  .3 

3. 

PHASE 

3 

0.50 

2 

Figure  32.  Scenario  File  Report. 


bounds.  In  fact,  the  lower  bound  is  very  close  to  the  true 
MCSP  for  this  mission. 

The  lower  bound  will  generally  be  "tight"  if  the  mission 
has  only  one  demanding  phase  or  the  last  demanding  phase  in¬ 
cludes  the  other  phases'  function  requirements;  the  upper 
bound  will  be  tight  if  the  system  does  not  contain  much  fault 
tolerance  (failure  resiliency  near  1.0)  or  if  only  the  first 
phase  is  demanding.  Unfortunately,  for  many  missions,  par¬ 
ticularly  those  with  many  phases,  the  bounds  diverge  widely. 
Therefore,  it  is  recommended  that  the  phase -by-phase  output 
be  used  to  compare  mission  phases  and  assess  weapons  deli- 
very  or  other  success  probabilities  within  a  mission,  and 
that  the  MCSP  and  pool  budget  output  be  used  to  compare  mis- 
sions  as  a  whole. 
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MCSP  AND  BUDGET  OUTPUT  OPTION 

CHAIN  NUMBER 

CHAIN  NAME 

SERIES/PARALLEL 

1 

FRONT  END 

SERIES 

POOL  NUMBER 

POOL  MCSP 

10 

1  1 

12 

CHAIN  MCSP: 

0.999850 

0  999970 

1  000000 
0.999820 

2.3 

DIGITAL 

PARALLEL 

TYPE  N  POOL  MCSP: 

TYPE  C  POOL  MCSP: 

TYPE  S  POOL  MCSP: 

TYPE  F  POOL  MCSP: 

0.999700 

1  000000 
0.999400 
0.999880 

CHAIN  MCSP  (BOTH  CHAINS  OPERABLE): 
CHAIN  MCSP  (PRIMARY  CHAIN  ONLY): 
CHAIN  MCSP  (SECONDARY  CHAIN  ONLY): 
CHAIN  MCSP: 

0.998980 

0 . 000000 
0.000000 
0.998980 

IMMEDIATE  REPAIR  MTBCF. 

TOTAL  SYSTEM  MCSP  AT  TIME  3.00  HOURS: 

2500. 

0  998801 

Fij 

>ure  33 .  MCSP  and 

Pool  Budget 

Output . 

PHASE-BY-PHASE 

MCSP  REPORT 

TIME  INTO 

SUCCESS  PROBABILITY  1 

MISSION 

CURRENT  PHASE 

LOWER  BOUND 

UPPER  BOUND 

0.00 

START  OF  MISSION 

1  000000 

1  000000 

1 .50 

PHASE  1 

0  999985 

0  999985 

250 

PHASE  2 

0.998985 

0,999585 

3.00 

PHASE  3 

0.998955 

0.999580 

SYSTEM  MCSP 

0  998955 

0  999580 

IMMEDIATE 

REPAIR  MT8CF(HOURS) 

2870 

71  40 

Figure  34. 


Phase-by-Phase  MCSP  Output, 


The  BIT  option  can  be  used  to  investigate  the  impact  of 
imperfect  switching,  due  to  incomplete  testability,  on  MCSP. 
Figure  35  gives  upper  and  lower  bounds  on  MCSP,  taking  into 
account  imperfect  BIT.  Testability  causes  seven  or  eight  fail 
ures  per  100,000  missions  for  this  example.  For  systems  with 
high  undetected  failure  rates  or  high  failure  resiliency,  the 
contribution  of  BIT  will  be  more  significant.  The  probability 
of  a  false  mission  failure  indication  is  shown  to  be  less  than 
two  in  100,000. 


TESTABILITY 

FACTORS  REPORT 

BIT 

OPTION 

MISSION  DURATION  - 

3.00  HOURS 

LOWER  BOUND 

UPPER  BOUND 

PERFECT  BIT  MCSP 

0.99880065 

0.99880065 

IMPERFECT  BIT  MCSP 

0.99871965 

0.99873525 

PROBABILITY  OF  MISSION 
FAILURE  DUE  TO  BIT 

0.00008100 

0.00006540 

MISSION  FAILURE  FALSE 
ALARM  PROBABILITY 

0.00000227 

0.00001794 

Figure  35.  Testability  Factors  (BIT)  Output. 


5 . 2  Logistics/Sustainability  Analysis 

MIREM  can  be  used  to  evaluate  logistics  impacts  in  terms 

2 

of  high  removal  rate  items  and  bare-base  sustainability  by 
using  the  LRM/LRU  budget,  MTBCF ,  and  full  BIT  output  options. 
The  LRM/LRU  budget  results  for  the  input  files  shown  in  Sec¬ 
tion  5.1  are  listed  in  Figure  36.  It  should  be  noted  that  the 
relative  contribution  of  LRMs/LRUs  depends  on  the  operating 


LRM/LRU  BUDGET  REPORT 


TOTAL  OPERATING  TIME:  46  00  HOURS 
MISSION  DURATION  3.00  HOURS 


LRM/LRU 


MARGINAL 

MCSP 

(CUMULATIVE) 


RELATIVE 

CONTRIBUTION 

(CUMULATIVE) 


PROBAB I L I TY 
OF  REMOVAL 
UPON  REPAIR 


FRONT END 
DIGITALA 
DIGITALS 
INTERCONNECTIONS 


0  845040 
0.921967 
0.880019 

N/A 


0  130  0  103612 
0.562  0.588351 
0.326  0  367499 
N/A  N/A 


SYSTEM  MCSP  (CUMULATIVE) :  0.821932 

SYSTEM  MCSP  (LAST  MISSION)'  0  998496 


Figure  36.  LRM/LRU  Budget  Output. 


2Bare-base  maintenance  scenarios  are  characterized  by  no 
off-equipment  LRM/LRU  repair  and  limited  spares  with  which  to 
perform  on-equipment  repair. 
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time  since  repair.  The  total  operating  time  has  been  set  to 
MTBF  to  give  a  better  indication  of  high  removal  rate  items 
under  a  deferred  repair  policy.  The  value  MTBCF  is  also  use¬ 
ful.  This  system  contains  three  LRUs;  no  interconnections 
were  modeled.  The  Digital  A  LRU  is  the  largest  contributor  to 
critical  failures  (56%).  If  this  LRU  never  failed,  cumulative 
MCSP  would  increase  from  0.82  to  0.92.  The  probability  of 
removing  the  LRU  upon  repair  is  about  0.59;  summing  these  num¬ 
bers  across  LRUs  shows  that  the  average  number  of  LRUs  removed 
is  1.06.  These  probabilities  can  be  combined  with  MTBCF  to 
give  the  LRU  removal  rates  under  deferred  repair,  which  will 
be  somewhat  lower  than  the  traditional  LRU  failure  rate. 


The  MTBCF  results  for  the  same  architecture  and  mission 
are  shown  in  Figure  37.  The  MTBCF  of  1459  hours  is  based  on 
the  assumption  that  no  repairs  are  made  before  critical  fail¬ 
ure.  Bare-base  operations,  for  example,  generally  have  this 
characteristic.  In  contrast,  the  immediate  repair  MTBCF  of 
2499  hours  assumes  that  the  system  is  fully  repaired  after 
each  3-hour  mission.  For  highly  fault- tolerant  systems, 


MTBCF 

REPORT 

MEAN  TIME  BETWEEN 

CRITICAL  FAILURES  (MTBCF): 

1459  HOURS 

MEAN  TIME  BETWEEN 

FAILURES  (MTBF): 

446.  HOURS 

FAILURE  RESILIENCY: 

3  27 

INTEGRATION  INTERVALS 

MIDPOINT 

WIDTH 

FAILURE  RATE 

AREA 

(HOURS) 

(HOURS) 

(E-6/HOURS) 

(HOURS) 

5  58 

11  16 

400. 1 

11  14 

33  48 

44  64 

401  .5 

44.05 

145.09 

178.57 

417.7 

168.34 

591  52 

714.29 

553.4 

542  43 

1 143. 58 

389.84 

733  5 

208  65 

1502  95 

328.91 

830.4 

132.99 

1 744  00 

153  20 

885.9 

50  14 

1944.09 

246.97 

926.2 

67.65 

2182  62 

230.09 

969. 1 

50  27 

2402  97 

210  62 

1004.2 

37.01 

2607.09 

197.61 

1033.2 

28. 19 

2800  19 

188.58 

1058.1 

21  98 

298536 

181.76 

1079.8 

17.38 

3173.08 

193.70 

1100.0 

15.11 

3386.50 

233.  13 

1120.8 

14  38 

3647.67 

289.22 

1143.8 

13  34 

3981 .85 

379.13 

1169.5 

12.00 

4441  52 

540  20 

1199  5 

10.18 

5153.89 

884.55 

1236.4 

7  64 

6532  02 

1871 .70 

1285.3 

4.43 

10758.80 

6581 .86 

1350  4 

1  29 

NUMBER  OF  MCSP  EVALUATIONS: 

24 

NUMBER  OF  INTERVALS; 

21 

STOPPING  POINT: 

14049  73  HOURS 

FINAL  MCSP: 

CONSTANT  FAILURE 

RATE  MTBCF: 

2499  HOURS 

MTBCF  Output 


the  immediate  repair  MTBCF  result  can  be  unrealistically  high 
because  it  does  not  take  into  account  undetected  and  intermit¬ 
tent  failures,  replacement  of  the  wrong  item,  and  other  factors 
that  degrade  real-world  maintenance  performance.  The  degree  of 
fault  tolerance  is  best  seen  in  the  failure  resiliency  (3.27), 
which  roughly  corresponds  to  the  number  of  resource  failures  until 
critical  failure. 


The  additional  output  in  Figure  37  (starting  with  "inte¬ 
gration  intervals")  was  generated  by  requesting  intermediate 
results  to  be  printed.  This  output  traces  the  progress  of 
the  numerical  integration  algorithm  that  computes  MTBCF.  The 
algorithm  required  24  MCSP  evaluations  and  therefore  used  nearly 
24  times  as  much  computer  time  as  the  MCSP  and  pool  budget 
output.  For  this  reason,  MTBCF  outputs  are  not  recommended 
for  test  or  sensitivity  runs.  The  algorithm  stopped  at  an 
operating  time  of  14,000  hours,  at  which  point  the  probability 
of  no  critical  failures  (MCSP)  was  insignificant.  For  constant 
failure  rate  systems  (little  fault  tolerance),  the  algorithm 
will  stop  much  sooner  and  still  give  accurate  results  (see 
Appendix  A. 6).  Plotting  the  failure  rate  against  the  operating 
time  since  repair  (use  the  "midpoint"  column  in  Figure  37) 
illustiates  the  impact  on  MCSP  of  performing  missions  with 
degraded  systems  under  a  deferred  repair  policy.  Figure  38 
shows  that  the  failure  rate  (and  hence,  the  mission  failure 
probability)  doubles  for  a  system  that  has  operated  for  the 
MTBCF  without  a  critical  failure  and  without  repair. 
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OPERATING  TIME  SINCE  REPAIR  (HOURS) 


Figure  38. 


Failure  Rate  as  a  Function  of  Operating  Time. 


MTBCF  results  that  include  testability  factors  can  be 
obtained  by  selecting  the  full  BIT  output  (Figure  39).  For 
this  example,  imperfect  BIT  reduces  MTBCF  from  1459  hours  to 
between  1427  and  1436  hours.  Again,  systems  with  high  unde¬ 
tected  failure  rates  or  high  failure  resiliency  will  have  a 
more  significant  degradation. 


TESTABILITY 

FACTORS  REPORT 

BIT  MTBCF  OPTION 

MISSION  DURATION  - 

3.00  HOURS 

LOWER  BOUND 

UPPER  BOUND 

MTBCF 

1427.09 

1436.09 

mtbf 

446.43 

446  43 

FAILURE  RESILIENCY 

3.20 

3.22 

MCSP  AT  TIME  T 

0.998719647 

0.998735245 

Figure  39.  Testability  Factors  (BIT)  MTBCF  Output. 


All  of  the  performance  measures  described  up  to  this  point 
depend  on  the  mission  scenario.  A  useful  measure  that  is  not 
related  to  a  mission  is  MTBFF  for  each  function  performed  by 
the  system.  Figure  40  lists  the  success  probability  (MCSP), 
MTBFF,  and  failure  resiliency  for  each  function.  GPS  has  a 
much  lower  failure  resiliency  than  the  other  functions  because 
the  L-Band  Front  End  and  several  Digital  A  resources  are  single 
point  critical  failures  with  respect  to  GPS. 


MTBFF  REPORT 

TOTAL  OPERATING  TIME.  3  00  HOURS 

MTBCF 


FUNCTION 


GPS 

UHF 

SINC 


MCSP 


0  999488 
0  999970 
0  999970 


Ik*4EDI  ATE 
REPAIR 


5853. 
99007 . 
98855. 


DEFERRED 

REPAIR 


1967. 

4224 

4055. 


FAILURE 

RESILIENCY 


4  41 
9  46 
9  08 


MIREM  can  be  used  to  evaluate  the  impact  of  innovative 
repair  policies  on  mission  reliability  and  availability,  using 
the  repair  output  option.  The  results  for  the  example  of  Sec- 
tion  5.1  are  shown  in  Figure  41.  Average  MCSP ,  or  equivalently, 
MTBCF,  is  highest  for  the  immediate  repair  policy  and  lowest 
for  the  deferred  repair  policy,  which  maintains  the  system  in 
the  poorest  state  of  repair.  Reliability  measures  cannot  be 
computed  for  the  repair  at  degraded  level  policy  because  this 
example  contains  parallel  chains.  Conversely,  MTBMA  is  least 
for  immediate  repair.  The  scheduled  maintenance  policy,  with 
a  maintenance  interval  of  100  hours,  only  increases  MTBMA  from 
446  to  447  hours.  By  repairing  at  degraded  levels,  an  average 
of  almost  two  faults  are  repaired  at  each  maintenance  time, 
extending  MTBMA  to  745  hours.  Under  deferred  repair  MTBMA  is 
merely  MTBCF  -  maintenance  corresponds  to  critical  failures. 

Because  the  model  neglects  the  reduction  in  failure 
rate  that  results  from  operating  with  failed  resources,  the 
same  number  of  repairs  must  be  performed  under  each  mainte¬ 
nance  policy.  Availability  is  greater  for  policies  with  large 
MTBMA,  because  multiple  repairs  are  performed  simultaneously. 

If  series  (sequential)  repair  were  selected,  all  policies 
would  give  the  same  availability. 


REPAIR  POLICY  REPORT 

MISSION  DURATION  - 

3.00  HOURS 

QUANTITY 

IVWED1ATE 

REPAIR 

DEFERRED 

REPAIR 

SCHEDULED 

MAINTENANCE 

REPAIR  AT 

DEGRADED 

LEVEL 

AVERAGE  MCSP 

0.998800646 

0.997945310 

0.998791206 

«•  N/A  •• 

MTBCF 

2500. 

1459. 

2480. 

• »  N/A  • • 

MTBMA 

4*6,43 

1456.57 

488.42 

745.35 

MTTR 

2.24 

4.00 

2.27 

2.42 

INHERENT 

AVAILABILITY 

0.99501 

0.99727 

0.99537 

0.99676 

STTT17 


si 


5.4 


Sensitivity  Analysis 

MIREM  can  be  used  to  quickly  evaluate  the  impact  of  sys¬ 
tem  changes  on  reliability,  and  can  thus  be  a  useful  aid  for 
designing  fault  tolerance  into  complex  systems.  The  sensitiv¬ 
ity  to  resource  reliability,  redundancy,  and  reconfigurability 
can  be  easily  analyzed.  The  MCSP  and  pool  budget  output  option 
is  recommended  for  sensitivity  analysis.  If  the  mission  length 
is  used  as  the  total  operating  time,  then  the  study  will  show 
the  impacts  on  mission  reliability  for  a  full-up  system.  If 
the  system  MTBCF  (or  MTBF ,  if  MTBCF  has  not  been  calculated) 
is  used  as  the  total  operating  time,  the  study  will  show  the 
impacts  on  bare-base  substainability  when  deferred  repair  con¬ 
cepts  are  employed. 

The  sensitivity  of  MCSP  to  various  system  changes  for  the 
architecture  and  mission  of  Section  5.1  is  shown  in  Table  10. 
Adding  a  second  signal  processor  to  Digital  A  reduces  the 
number  of  mission  failures  by  55%.  This  change  is  entered  in 
the  architecture  file  by  changing  the  number  of  branches  in 
pool  14,  chain  2  from  one  to  two.  Adding  a  third  L-band  re¬ 
ceiver  and  switch  port  requires  more  file  modifications:  A 
separate  pool  is  created  for  the  L-band  antenna  connector; 
pool  10  is  modified  to  have  three  branches,  each  containing 
one  receiver  and  switch  port;  and  the  GPS  utilization  for 
pool  10  is  changed  to  two.  Allowing  GPS  to  use  Digital  B  is 
accomplished  by  adding  GPS  (function  1)  to  the  function  list 


Table  10.  Sensitivity  of  MCSP  to  Conf iguration  Changes 


Configuration  Option 

MCSPa 

A ( 1 -MCSP ) 
(%) 

Add  signal  processor  to  Digital  A 

0.99946 

-55 

Add  preprocessor  to  Digital  A 

0.99880 

0 

Add  L-band  receiver  and  switch  port 

0.99892 

-10 

Add  switching  to  allow  GPS  to  use 

0.99910 

-25 

Digital  B 

Isolate  the  signal  processor  in  each  LRU 

0.99880 

0 

aBase 1 ine  MCSP  =  0.99880. 
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and  adding  GPS  utilization  rates  for  chain  three.  Isolating 
the  signal  processors  is  accomplished  by  changing  their  pool 
type  to  C  in  both  pools.  As  this  leaves  no  type  S  pools,  the 
type  F  pools  may  also  be  changed  to  type  N.  The  result  that 
some  architecture  changes  have  no  perceptible  effect  on  MCSP 
may  be  counterintuitive.  This  insensitivity  arises  when  the 
architecture  change  affects  mission  success  only  in  the  rare 
event  of  several  specific  resource  failures.  Adding  a  pre¬ 
processor  to  Digital  A,  for  example,  is  only  helpful  if  two 
preprocessors  fail  in  that  LRU.  The  sensitivity  to  these 
changes  may  increase  if  the  total  operating  time  is  increased. 


6.  ADVANCED  APPLICATIONS 


This  chapter  provides  suggestions  on  applying  MIREM  to 
more  complex  systems  that  do  not  fit  readily  into  the  model 
framework  defined  in  Chapter  2.  Special  procedures  and  approx 
mation  techniques  will  be  provided.  These  suggestions  are 
based  on  experience  gained  in  applying  MIREM  to  the  ICNIA  sys¬ 
tem  definition  architectures. 


6 . 1  Resource  Pool  Approximations 

The  methodology  for  identifying  resource  pools  given  in 
Section  3.5  does  not  apply  exactly  to  some  architectures.  The 
following  architecture  design  peculiarities  may  be  encount¬ 
ered  : 

1.  Parallel  branches  within  a  pool  are  not  all  the  same. 

2.  Pool  boundaries  (parallel  structures)  differ  for  dif¬ 
ferent  functions. 

3.  Type  C  pools  in  parallel  chains  do  not  occur  in  pairs 


6.1.1  Branches  Differ 

If  a  pool  contains  branches  with  different  failure  rates, 
a  good  approximation  is  to  use  the  average  branch  failure  rate 
It  may  be  necessary  to  change  the  resource  data  to  define  a 
resource  with  the  desired  failure  rate. 

6.1.2  Pool  Boundaries  Differ 


Pool  boundaries  can  differ  across  functions  because  of 
switching  limitations.  For  example,  if  the  low-band  LRU  in 


Figure  7  were  connected  to  only  two  preprocessors  in  Digital  A, 
these  two  preprocessors  would  be  a  pool  with  respect  to  UHF . 
These  preprocessors  would  then  be  entered  twice  in  Table  4, 
once  in  a  three-branch  structure  for  GPS  and  once  in  a  two- 
branch  structure  for  UHF  and  SINCGARS.  However,  MIREM  assumes 
that  pool  boundaries  are  the  same  for  all  functions.  This 
situation  can  be  approximated  by  forming  a  pool  from  the  set 
of  branches  with  the  least  redundancy  and  putting  any  leftover 
branches  in  a  separate  pool.  For  the  mission  defined  in  Fig¬ 
ure  32,  three  branches  are  required  from  the  three-branch 
structure  (GPS  plus  SINCGARS),  and  one  branch  is  required  from 
the  two-branch  structure  (UHF  or  SINCGARS  in  separate  phases). 
Therefore,  a  three-branch  pool  should  be  formed  since  it  con¬ 
tains  no  redundancy.  This  formulation  is  approximate  in  that 
it  allows  low-band  functions  to  use  preprocessor  3.  Forming 
two  pools  would  mean  that  GPS  must  use  preprocessor  3  and  either 
preprocessor  1  or  preprocessor  2. 

Pool  boundaries  can  also  differ  across  functions  with 
regard  to  how  many  resources  are  on  a  branch.  In  this  case, 
the  larger  set  of  resources  should  be  used  in  MIREM  to  define 
the  branches. 

6.1.3  Singleton  Type  C  Pools 


MIREM  assumes  that  type  C  pools  in  parallel  chain  pairs 
occur  in  pairs,  one  in  each  chain.  If  a  singleton  pool  occurs 
add  a  pool  with  the  same  number  of  branches  and  utilizations 
to  the  other  chain.  Define  a  dummy  resource  with  zero  failure 
rate  to  put  in  the  added  pool. 

6.2  Modeling  Resource  Scheduling  with  Utilization  Rates 


The  methodology  for  assigning  pool  types  and  utilizations 
presented  in  Section  3.5  is  intended  to  specify  the  number  of 
branches  required  in  a  pool  to  perform  each  combination  of 
functions.  However,  for  systems  that  share  resources  between 
functions  according  to  a  complex  schedule,  the  methodology  may 
not  apply.  Pools  may  be  contending  with  respect  to  some  func¬ 
tions  and  noncontending  with  respect  to  others.  Several  tech¬ 
niques  can  be  used  to  model  resource  scheduling. 

The  most  desirable  approach  is  to  label  ambiguous  pools 
as  type  C  and  then  define  fractional  utilizations  in  such  a  way 
that  noncontending  functions  add  correctly.  One  such  situation, 
and  the  utilizations  used  to  model  it,  is  shown  in  Table  11. 

For  more  complex  situations,  it  may  be  necessary  to  define  two 
utilizations  for  each  function:  one  to  be  used  if  a  key  function 
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Table  11.  Fractional  Utilizations  for  a  Partially 
Contending  Resource  Pool 


Functions  Required 

1 

2 

3 

■ 

lO  Uui  uLli-lZaLlun 

X 

0.1  (1) 

X 

0.1  (1) 

X 

2.0  (2) 

X 

X 

0.2  (1) 

X 

X 

2.1  (3) 

X 

X 

2.1  (3) 

X 

X 

X 

2.2  (3) 

is  required,  the  other  if  it  is  not.  These  two  utilizations 
can  be  stored  in  separate  architecture  files  and  used  for  the 
appropriate  missions.  In  the  case  of  a  series  chain,  this 
practice  can  be  taken  as  far  as  necessary,  even  to  the  point 
of  defining  new  utilizations  for  each  mission  phase  ("functions" 
then  become  mission  phases).  However,  on  parallel  chains,  the 
total  utilization  for  each  subset  of  the  required  functions  is 
needed  to  correctly  compute  reliability;  therefore,  the  technique 
should  be  used  with  caution. 

Another  situation  that  can  be  resolved  through  utiliza¬ 
tion  rates  is  a  shared  pool  pair  that  is  utilized  in  a  non¬ 
contending  fashion.  MIREM  assumes  that  all  type  S  pools  are 
contending  (utilizations  add).  The  desired  effect  can  be 
achieved  by  setting  all  utilizations  to  0.01,  except  possibly 
for  one  function  that  requires  more  than  one  branch  -  reduce 
its  utilization  from  n  to  n  -  0.5. 


Resource  Chain  Approximations 


The  methodology  for  identifying  resource  chains  given  in 
Section  3. A  does  not  apply  exactly  to  some  architectures.  The 
following  peculiarities  may  be  encountered: 

1.  More  levels  of  redundancy. 

2.  Chain  boundaries  (top-level  switching  points)  differ 
for  different  functions. 


6.3.1  General  Series/Parallel  Structures 


If  more  than  two  levels  of  redundancy  occur  in  the  system 
or  more  than  two  redundant  paths  occur  at  the  higher  level 
(more  than  two  parallel  chains),  the  group  feature  of  Sec¬ 
tion  2.3.2  can  be  used  to  create  a  general  series/parallel 
structure.  However,  this  prevents  the  feature  of  contention 
between  functions  (e.g.,  dedicated  resources  or  contention  for 
throughput  of  a  data  processor)  and  resource  sharing  from  being 
modeled.  When  these  features  are  significant,  the  lowest  level 
of  redundancy  in  the  system  may  have  to  be  neglected  to  allow 
modeling  in  MIREM. 


6.3.2  Chain  Boundaries  Differ 


APPENDIX  A:  MIREM  EQUATIONS 


This  appendix  describes  the  equations  and  algorithms  used 
in  the  Mission  Reliability  Model  (MIREM).  The  model's  basic 
function  is  to  evaluate  the  combinations  of  failures  which 
result  in  failure  of  a  particular  mission  and  compute  the 
probability  of  such  failures.  Intrinsic  hardware  reliability 
is  not  predicted  by  the  model  but  is  treated  as  an  input.  The 
general  problem  is  defined  in  Section  A.l,  and  the  special 
class  of  problems  that  will  be  solved  is  presented  in  Sec¬ 
tion  A. 2.  Reliability  is  computed  in  Sections  A.  3  and  A. 4. 
Some  additional  model  outputs  are  derived  in  Sections  A. 5, 

A. 6,  and  A. 9.  Section  A. 7  generalizes  the  problem  to  consider 
imperfect  switching;  and  Section  A. 8,  to  consider  repair. 


A. 1  The  Phased  Mission  Reliability  Problem 

Assume  that  the  system  consists  of  n  resources  or  "failure 
units"  with  constant  failure  rate.  The  traditional  approach  is 
to  represent  system  health  by  X,  where  X^^  is  equal  to  1  if 

component  i  is  good  at  the  end  of  the  mission,  and  0  other¬ 
wise.  For  each  mission  M,  the  system  structure  function 

{1  if  the  mission  M  can  be  supported 
with  system  health  X 

0  otherwise 


is  determined  and  MCSP  is  just  Pr{0^(X)  = 

0 

mission  with  m  phases  by  letting  X^  equal 

up  at  the  end  of  phase  £  and  0  otherwise, 
structure  function  for  phase  £.  Then 


1}.  Define  a  phased 
1  if  component  i  is 
and  let  <))^(*)  be  the 


m 

MCSP  =  JJ  Pr{<p£(X£)  =  1  |  <)>h(Xh)  =  1,  h=l,  ...,  £-1} 
£=1 


m 

>  Pr{<j>£(X)  =  1}  (1) 

£  =  1 
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Even  in  the  single-phase  case,  this  approach  is  practical  only  j 

if  the  system  has  few  components  or  has  a  special  modular  struc-  • 

ture.  Furthermore,  in  order  to  analyze  various  mission  require-  ! 

o 

ments,  it  is  desirable  to  express  4>  at  the  individual  function 
level  rather  than  for  a  phase.  Phases  with  various  function  j 

requirements  can  then  be  formulated  if  a  "combining"  operation 
is  defined  on  the  functional  structures. 


A. 2  A  Special  Structure  for  Integrated 

^Reconf igurable  Electronics 


£ 

For  the  reasons  discussed  above,  <|>  will  not  be  .dealt 
with  explicitly.  Instead,  the  special  structure  of  <(>  which 
has  been  observed  in  advanced  avionics  architectures  will  be 
exploited  to  allow  more  efficient  computations. 

Chain  Structures  -  Assume  that  the  system  can  be  described 
by  either  a  one-level  or  two-level  structure.  A  one-level 
structure  consists  of  a  set  of  k-of-n  modules  in  series.  These 
k-of-n  modules  will  be  referred  to  as  pools .  Each  parallel 
branch  in  a  pool  contains  one  or  more  resources  in  series 
(branches  are  identical).  The  number  of  branches  (k)  required 
in  a  pool  depends  on  the  function  requirements.  Pools  that 
are  irrelevant  (i.e.,  k  equal  to  0)  with  respect  to  certain 
functions  are  allowed. 

A  two-level  structure  consists  of  a  set  of  one-level  struc¬ 
tures.  Each  one-level  structure  will  be  referred  to  as  a  chain . 
Chains  are  either  in  "series"  in  the  sense  that  all  functions 
must  use  the  chain,  or  "parallel"  in  the  sense  that  a  set  of 
functions  is  supportable  if  there  exists  an  allocation  of  func¬ 
tions  to  parallel  chains  such  that  each  chain  can  support  its 
functions.  Some  functions  may  be  restricted  to  certain  chains. 
Note  that  parallel  chains  are  not  modules  (i.e.,  not  a  series- 
parallel  structure).  Instead  of  simply  up  or  down,  these  chains 
must  be  described  by  the  combinations  of  functions  which  they 
can  support.  The  current  implementation  of  MIREM  allows  only 
two  chains  in  parallel  (chain  pairs),  although  generalization 
is  possible. 

A  slight  generalization  to  this  model  is  also  considered. 
The  allocation  of  functions  to  parallel  chains  may  not  be  strict 
in  that  pools  may  be  shared  between  parallel  chains.  For  ex¬ 
ample,  processing  resources  in  parallel  chains  may  be  shared 
if  the  resources  communicate  through  data  buses. 

Series-Parallel  Structures  -  General  series-parallel  struc¬ 
tures,  with  more  than  the  two  levels  described  above,  will 
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also  be  considered  by  organizing  pools  into  k-of-n  structures 
within  a  series  chain. 


Single-Chain  Computations 


For  pools  in  a  single  chain,  let 


C^(t)  =  number  of  good  branches  in  pool  i  at  time  t 

u^j  =  utilization  of  pool  i  by  function  j 

c  .  =  number  of  branches  in  pool  i  (no  failures) 
max  ,1 

Now  define  two  types  of  pools,  according  to  how  functions  com¬ 
bine.  If  a  set  of  functions  is  required  in  phase  £,  the 

total  requirement  for  pool  i  in  phase  £  is 


y  '  u^  if  pool  i  is  contending 

max  u. .  if  pool  i  is  noncontending 

jeF.  1J 


Also  let 


ri  = 


£  =  1 ,  .  .  .  ,m 


If  the  functions  are  not  required  simultaneously,  all  pools 
are  considered  noncontending. 

Assume  that  the  system  is  initially  fully  repaired,  so 
that  Pr{C.(0)  =  c  .}  =  1,  and  that  the  time  until  failure 

X  niaX  y  X 

of  each  resource  is  exponentially  distributed.  Then  for  active 
redundant  pools,  the  exponential  failure  time  distribution  implies 
that 


Pr{C.(t)  =  k} 


/c  \ 

_  /  max , 1  \ 

\  k 


c  .  -k  , 

,  x  max,i  / ,  xk  ,  .  „ 
(p)  (1-p)  ,  k  <  c 


max ,  i 


v'.-.- v'-- 


where 


t  =  operating  time 

\  =  branch  failure  rate  (sum  of  resource  failure 
rates  on  a  branch) 


For  standby  redundant  pools,  only  the  required  number  of  branches 
in  each  phase,  approximated  by  r^  ,  are  subject  to  failures: 


Pr{Ci(t)  = 


k} 


=  <r.\t) 


c  -  k 

max ,  i 


-r.\t 
e  1  /(c 


max ,  1 


•k) 


(5) 


Using  the  approximation  of  Equation  1,  MCSP  for  a  single  chain 
is  just 

MCSP  =  JJ  Pr{C.(t)  >  r.}  (6) 

pool  i 


which  can  be  easily  computed  from  Equations  4  or  5. 

If  the  chain  is  cascading  (that  is,  it  contains  groups  of 
noncontendings  pools  in  k-of-n  structures),  the  reliability  is 
computed  by  starting  with  the  smallest  groups  and  working  out. 
Let 


ng  =  number  of  subgroups  (pools  or  groups)  con¬ 
tained  in  the  group 

p-  =  MCSP  (reliability)  of  subgroup  j,  j=l,..,n 
J  s 

r  =  requirement  for  the  group  (computed  in  the 
same  manner  as  for  noncontending  pools) 

i  .  =  0  or  1,  j  =  l, . . . ,nc 


The  group  MCSP  is 


MCSPGROUP  =  TT 

Ul>r  j=l 


i.  1-i . 

PjJ(i-Pj)  J 


(7) 


By  defining  the  largest  group  to  contain  the  whole  chain,  the 
last  group  MCSP  computed  will  be  the  chain  MCSP. 


A. 4  Parallel  Chain  Computations 

Now  consider  a  two-level  structure  containing  two  parallel 
chains.  Pools  are  divided  into  the  following  pool  types: 

F:  chain-fail  pools  (noncontending) 

S:  shared  pools  (contending) 

N:  noncontending  pools,  excluding  types  F  and  S 

C:  contending  pools,  excluding  types  F  and  S 


All  type  S  and  type  C  pools  in  parallel  chains  must  occur  in 
pairs,  one  in  each  chain.  Pool  pairs  must  have  the  same  func¬ 
tion  utilization  rates.  A  pair  of  pools,  one  in  each  chain, 
is  type  S  if  each  pool's  resources  can  be  used  by  functions 
allocated  to  the  opposite  chain.  Type  F  pools  are  those  which, 
upon  failure,  prevent  the  entire  chain  (including  type  S  pools) 
from  being  utilized.  The  remaining  pools  are  classified  as 
type  N  or  type  C  according  to  Equation  2.  For  the  requirement 
calculation  of  Equation  2,  type  F  pools  are  treated  like  type  N, 
and  type  S  pools  are  treated  like  type  C.  If  functions  are 
not  required  simultaneously,  type  C  and  type  S  pools  are 
treated  as  type  N. 

Define  the  following  function  sets: 


m 

cf  =  U  F* 

4  =  1 

CFCOM  =  {functions  in  CF  that  can  use  either  chain 
in  the  pair} 

K 

CF  =  {functions  in  CF  that  must  use  chain  k) 
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ft 


FCOM£  =  {functions  in  F.  that  can  use  either  chain 
in  the  pair} 

F^  =  (functions  in  F^  that  must  use  chain  k} 

for  k=l  (primary  chain)  and  k=2  (secondary  chain).  The  state 
of  a  chain  as  determined  by  its  C.  implies  the  ability  to  sup¬ 
port  certain  functions.  Let  1 


Xk  = 


xk  = 


UPK(a )  = 


UP1+2  (of )  = 


1  if  function  j  can  be  supported  after 
operating  for  time  t  on  the  type  N 
pools  on  chain  k, 

0  otherwise 
[X^],  jeCFCOM 

the  event  that  the  set  of  functions  CF  can  be 
supported  after  operating  for  time  t  on  the 
type  a  pools  on  chain  k 

the  event  that  the  set  of  functions  CF  can  be 
supported  after  operating  for  time  t  on  the 
type  a  pools  on  the  pair  of  parallel  chains 


for  k=l  (primary)  and  k=2  (secondary)  and  a  =  F,  S,  N,  C.  The 

1+2  k 

event  UP  (C)  is  dependent  upon  X  in  that  an  allocation  of 
functions  to  chains  that  is  supportable  on  the  type  C  pools 
must  be  consistent  with  the  supportability  of  functions  on  the 

1+2 

type  N  pools.  Similarly,  the  event  UP  (S)  is  dependent  on 

UP  (F).  Applying  these  definitions  and  using  the  phase  approx¬ 
imation  of  Equation  1, 

MCSP  =  Pr{ UP1+2  (F ,S ,N ,C) } 

=  Pr{UP1+2(C) |UP1+2(N)}  •  Pr { UP1+2 (N ) } 

•  Pr{UP1+2(S) |UP1(F) ,UP2(F)}  •  Pr{ UP1 ( F ) }  Pr{UP2(F)} 

+  Pr{ UP1 (S ,N ,C ) }  •  Pr { UP1 (F ) }  •  [1  -  Pr{UP2(F)}] 

+  Pr{UP2(S ,N ,C) }  •  Pr{UP2(F)}  •  [1  -  Pr{UP1(F)}] 


The  three  terms  in  Equation  8  correspond  to  both  chains  being 
up  with  respect  to  type  F  pools,  chain  1  being  up  and  chain  2 
being  up.  Two  algorithms  have  been  developed  to  compute  the 
first  term. 

A. 4.1  Quick  Algorithm 

This  approximate  algorithm  will  work  for  most  problems. 
In  the  current  software,  the  size  of  CFCOM  is  limited  to  eight 

if 

Conditioning  on  X  , 

Pr{UP1+2(C) |UP1+2(N)}  •  Pr{UP1+2(N) } 


-  £ 


1  2 

x-*-+xz  >  1 


Pr{UP1+2(C)  |  X1  =  x1,  X2  =  x^PrfX1  =  x^PrJX2  =  x 


(9) 


1/ 

The  distribution  of  X  is  determined  by  applying  the  single¬ 
chain  analysis  of  Section  A. 3  to  the  type  N  pools  for  all  sub¬ 
sets  of  the  functions  CFCOM  (the  functions  CF^  are  always  re- 

2 

quired  on  chain  1  and  the  functions  CF  are  always  required  on 
chain  2),  giving  Pr{X  x}  for  all  x.  The  law  of  total  proba 

if 

bility  is  then  used  to  obtain  Pr{X  =  x} . 


The  type  C  pools  are  treated  as  follows.  Assume  that 
type  C  pools  occur  in  pairs,  one  on  each  chain,  and  use  the 
index  i  to  refer  to  pairs  rather  than  individual  pools.  A 


superscript  will  be  used  to  indicate  chain  (e.g 


Ck 


c  .  )  . 
i '  max  ,  i 

The  utilizations  u^ ^  ,  however,  are  assumed  to  be  the  same  for 

both  chains.  The  allocation  of  functions  to  chains  is  repre¬ 
sented  by 


j  1  if  function  j  uses  chain  1 
(  0  if  function  j  uses  chain  2 


1  =  (yj  ,  je CFCOM 


ri  n'Z)  =  ^  Va  u.. 

jeFCOM£  J  1J 


(10a) 


E 


ri  0  **  ui  1 

jeFj  1J 


(10b) 


r . 


(10c) 


r  .  -  max  u .  . 
max,:L  jeCFCOM  11 


(10d) 


for  k-1,2.  The  conditional  event  in  Equation  9  occurs  if  there 
exists  an  allocation  y  such  that 


X2  <  y  <  X1 

(11a) 

(lib) 

i.2(i  -  +  rL  \  i  Ci 

(11c) 

for  all  type  C  pools  i.  That  is,  functions  can  be  assigned 
only  to  chains  on  which  the  type  N  pools  can  support  them,  and 
the  total  function  requirements  in  each  phase  must  not  exceed 
the  type  C  pool  capacities. 


A  necessary  condition  for  such  an  allocation  to  exist  i; 


max  |ri  (1 
t  =  l,  .  .  .  ,m  (  1»* 


x*)  +  r 


1  A  <  c1 

f  -  i 


(12a) 


k  0(1  -  x1)  +  r2  „  j  < 


max 


(12b) 


r  .  <  max  {C7,  Ct} 
max,i  —  1  i*  iJ 


(12d) 


for  all  type  C  pools  i.  The  probability  of  condition  11  will 
be  approximated  by  the  probability  of  condition  12c.  To  moti¬ 
vate  this  approximation,  note  that  condition  12c  requires  that 
sufficient  resources  be  available  to  perform  the  required  func¬ 
tions  in  each  phase.  Hence,  errors  occur  in  this  approxima¬ 
tion  only  in  calculating  the  probability  that  the  required 
resources  are  divided  in  usable  proportions  on  the  two  chains. 
There  are  two  reasons  why  condition  12c  may  not  be  sufficient: 

1.  Discrete  allocation  -  there  may  be  no  division  of 
FCOM^  that  matches  the  available  resources  in  each  chain. 

2.  Lockout  -  the  available  resources  in  pool  pair  i  may 
be  on  the  wrong  chain;  i.e.,  functions  are  "locked  out"  of 
that  chain  because  they  cannot  be  supported  by  other  type  C 
pools  or  by  type  N  pools. 

The  discrete  allocation  problem,  which  exists  only  if  u. .  takes 

■*-  J 

on  different  or  noninteger  values,  is  treated  by  condition  12d, 
which  ensures  that  the  largest  u^j  can  be  allocated.  This 

approximation  will  generally  be  very  good  when  there  is  at 
most  one  dominant  u^  (one  more  demanding  function).  The  lock¬ 
out  problem  for  type  N  pools  is  treated  exactly  by  condi¬ 
tions  12a-b;  functions  are  allocated  only  to  chains  on  which 
they  can  be  supported  by  the  type  N  pools.  If  there  is  more 
than  one  type  C  pool  pair,  lockout  between  these  resources 
will  not  be  captured.  Hence,  the  approximation  will  be  good 
if  there  are  few  "problem"  type  C  pools  and  will  be  optimistic 
if  there  are  a  number  of  such  pools. 

Using  condition  12, 

Pr{UP1+2(C) IX1  =  x1,  X2  =  x2} 


n/nax ,  i 

£ 

type  c  cl=h 
pools  i 


Pr{c} 


Pr{ C2  >  c2} 


(13) 


-  ‘  »  *  *  '  ■  ■  »  '  »  *  •  '  *  ’  A  «  *  >  ’  k'*  ,*«  -N  A  .  %  A  *»  A  \  \  '»  - 


where 


h  =  max  {r.  0(l-x^)  +  .,  r.  -  .} 

£  =  2  m  -  i,£*  1  max.i1 


^  m,ri-*<±'£l>  +  ri>2’  ^  '  C"ax’ii 


2  _ 
c  = 


)  c  if  c  >  r  .  , 

,  -  max , 1  ’ 

/  2 

'  max{c  ,  r  .}  otherwise 

ulaX  )  1 


A. 4. 2  Full  Algorithm 

This  exact  algorithm  will  work  for  almost  all  single¬ 
phase  problems  but  cannot  be  used  with  multiple  phases.  Hence, 
phase  subscripts  will  be  dropped  during  this  discussion.  Con¬ 
tinuing  along  the  lines  of  Equatior  lOa-b,  the  total  require¬ 
ment  in  pool  i  under  allocation  £  is 


TOT/  » 
ri  (x>  = 


/  E 

jeFCOM 


y  .  u .  .  + 
ij 


^  ^  u^  ,  type  C  pool  in  chain  1 

jeF1  J 

/  ^  (1-y  .  )u .  .  +  ^  u .  .  , 

jeFCOM  J  XJ  ^9  U* 


jeF 


max  u . . 
ij 

j:  jeFCOM  and  y.=l, 

1  J 

or  jeF 


type  C  pool  in  chain  2 


,  type  N  pool  in  chain  1 


max  u 


ij 

j:  jeFCOM  and  y.=0, 
2  J 

or  jeF 


,  type  N  pool  in  chain  2 


TOT  TOT 

If  allocations  y  and  z  satisfy  (y)  =  (z)  for  all  type  N 

and  type  C  pools  i,  then  they  will  be  called  substantively 
identical  allocations.  Define 


=  {allocations  that  are  not  substantively 
identical} 

=  order  of  A 


A(k)  =  {all  order  k  subsets  of  A} 


Allocation  y  is  possible  if  it  can  be  supported,  ^  r: 

1+2 

on  all  type  N  and  type  C  pools.  The  event  UP  (N,C)  corresponds 
to  at  least  cne  allocation  being  possible.  Denote  an  element 

of  A(k)  by  a  =  (y^ , . . . ,  yk) ,  and  let 

1  k 

p(a)  =  Pr{y  ,  . . . ,  y  are  all  possible  allocations} 


Then  the  law  of  total  probability  gives 


Pr{ UP1+2 (N 


,C)}  =  ( -l)k-1  P(a) 

k=l  aeA(k) 


(14) 


The  current  MIREM  software  limits  nQ  to  15,  which  corresponds 

to  about  32,000  terms  in  Equation  14.  Double-precision  arith¬ 
metic  is  used  to  reduce  the  effect  of  roundoff  error.  The 
evaluation  of  p(a)  has  the  same  form  as  a  series  chain 
computation : 


p(a)  = 


pool  i 
type  N  or  C 
in  chain  1  or  2 


Pr  {C±( t)  >  max{ri(y1) , . . . ,ri(yk)| } 


(15) 


A. 4. 3  System  Reliability 

Regardless  of  whether  the  quick  or  full  algorithm  is  used, 
the  type  S  pools  are  treated  as  follows.  Assume  that  type  S 
pools  occur  in  pairs,  one  on  each  chain,  and  use  the  same  nota¬ 
tion  as  for  type  C  pools.  Because  the  paired  resources  are 
shared,  only  the  combined  capacity  of  the  two  pools  need  be 
considered : 


Pr{UP1+2(S) |UP1(F) ,  UP2(F )}  =  "Tf  Pr{cJ  +  C2  >  r . } 

type  S  1  1  1 

pools  i 


'max ,  i 


:  TT  £ 

type  S  1 
pools  i  c 


Pr{ =  c1}  Pr{ C2  >  r±  -  c1}  (16) 


where 


h  = 


max  {r.  0(1)  - 


£  =  1 ,  .  .  .  ,m 


l  ,£  — 


C2  ■ ! 
max ,  l 


Applying  the  single-chain  analysis  to  the  type  F  pools 

gives  Pr{UP  (F)}.  This  completes  the  evaluation  of  the  first 
term  of  Equation  8. 

v 

To  evaluate  the  second  and  third  terms,  only  Pr{UP  (S,N,C)} 
is  needed.  It  is  obtained  by  applying  the  single-chain  analysis 
to  the  type  S,  type  N,  and  type  C  pools  using  the  set  of  func¬ 
tions  F0  for  phase  £.  Note  that  if  not  all  functions  in  CF 
x.  1  „ 

are  supported  on  chain  k  (CF  /  0  for  k-2  or  CF  /  0  for  k=l ) , 
then  Pr{ UPk( S ,N ,C ) }  =  0. 

Equation  8  gives  MCSP  for  a  pair  of  parallel  chains.  If 
the  system  contains  sever  il  chains  or  parallel  chain  pairs  in 
series,  with  reliabilities  MCSP.,  the  combined  reliability  is 


86 


MCSP  = 


(17) 


jy  Mcspi 

chain 

pairs 


A.  5  Phase  Sequence  Algorithm 

An  algorithm  is  presented  that  computes  upper  and  lower 
bounds  on  the  probability  that  each  mission  phase  is  success¬ 
fully  completed.  For  phase  £,  this  probability  is 

£ 

MCSP£  =  JJ  Pr{<|.h(Xh)=l  |  $k(Xk)=l,  k=l , . .  .  ,h-l}  (18) 

h=l 


The  MCSP^  bounds  culminate  in  MCSP  bounds  for  the  entire  mission 

after  the  final  phase  m.  The  calculations  in  Sections  A. 3 
and  A. 4  give  a  different  lower  bound  on  MCSP  because  of  the  as¬ 
sumption  in  Equation  2  that  all  phases  are  required  at  the  end 
of  the  mission;  that  approximation  is  not  made  here. 

Let 


mcsp£ 

MCSP^ 


duration  of  phase  £  (hours) 


t^  =  cumulative  time  after  £  phases 


lower  bound  for  MCSP£ 
upper  bound  for  MCSP^ 


Phase  £  is  said  to  be  dominated  by  phase  h  if  the  event  that 
the  functions  are  available  implies  that  the  functions  F£ 

are  available.  A  sufficient  condition  for  phase  £  to  be  dom¬ 
inated  by  phase  h  is  F.  c  F.  .  This  condition  will  be  used  to 
test  for  domination.  n 


In  the  following  algorithm, 


ND  =  set  of  nondominated  phases  among  phases  1,...,jH 

DT.  =  cumulative  duration  of  phase  £  plus  earlier  phases 
dominated  by  phase  £ 


Initialization.  ND  =  0; 


MCSPq  =  MCSPq 

Z=l;  Tn  =  0. 


1.  D  =  {phases  in  ND  that  are  dominated  by  phase  £} 


2-  +  E 


3.  =  Pr{ functions  F£  are  available  at  time  Tg} 

c 

P£  =  Pr{ functions  F£  are  available  at  time  DT^} , 

computed  by  applying  Sections  A. 3  and  A. 4  to  a 
one-phase  mission. 


4.  MCSp£  =  MCSP^  •  P^ 


5.  mcsp^  =  mcsp^  •  p^  /  7T  P ; 


6.  If  £=m,  then  stop;  MCSP^  is  for  the  whole  mission. 


7.  Update  ND  =  ND  -  D  +  {£} 


8.  £  =  £+1.  Go  to  step  1. 


The  tightness  of  these  bounds  tends  to  decrease  as  more 
phases  are  considered. 
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A.  6  Mean  Time  Between  Critical  Failure  Algorithm 

Another  measure  which  can  be  computed  by  MIREM  is  MTBCF, 
defined  as  the  expected  operating  time  without  repair  until  a 
critical  function  is  lost,  starting  with  full  system  capacity. 
Let  F(t)  be  the  MCSP  for  an  operating  time  of  t  hours.  Then 

oo 

MTBCF  =  ~  f  t  dF(t) 

0 


00 

=  J  F(t)dt 
0 


(19) 


This  integral  is  evaluated  in  MIREM  using  the  trapezoidal  rule 
with  a  variable  step  size  which  can  be  modified  by  exploration. 

1.  Select  a,  6,  emin,  erei  and  Initialize  tQ  =  0 , 

dt  *  tj  •  tQf  k  =  1. 

\1  =  ln[F(t0)/F(t1)]/dt 
A  =  [F(to)  +  F(t1)]dt/2 
MTBCF  =  A 

2.  dt(6)  =  0.86  dt/(A  \fc) 

3.  If  k  £  2,  dt  =  min{a  dt,  dt(6)}. 


If  k  >  2,  dt(erel)  = 


8F( tk.l)(0.8erel)/ 


2- 
d  F 

dt1 2 3 


1/2 


and  dt  =  min{a  dt,  max{dt(6),  dt(c  ,)}} 


4.  k  =  k  +  1* 


5.  tk  =  tk_^  +  dt 


FtV-FUk.i) 


•k-1 


tk-l  "  tk-2 


fck-2  ^ 


\k  =  ln[F(tk_1)/F(tk)]/dt 
A  =  (F(tk_1)  +  F(tk)]dt/2 

2- 

6.  If  erel  <  (dt)2  ^  /  [8F(tk_1) ] 

dt 


and  6  <  A  \k>  then  set  dt  =  dt/2  and  go  to  step  5. 

7.  MTBCF  =  MTBCF  +  A 

8.  If  F(tk)/\k  >  0.1 

.  |Ak  '  Vl» 

cind  c  •  '  »  / .  .  \  « 

““  Vck  •  Vi1 

then  go  to  step  2.  Otherwise,  set 

MTBCF  =  MTBCF  +  F(tk)/Xk 
and  stop. 


This  algorithm  is  based  on  the  assumption  that,  at  least 

for  large  t,  F(t)  can  be  approximated  by  ae  At.  Local  estimates 
of  \  serve  as  a  basis  for  selecting  a  step  size,  dt(6),  which 
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will  include  the  desired  fraction  6  of  the  entire  integral. 
Estimates  of  \  are  also  used  as  a  stopping  criterion.  If  the 
relative  change  in  A.  is  less  than  em;£n  per  unit  change  in  t, 

it  is  assumed  that  the  remainder  of  F  has  a  constant  failure 
rate  and  it  is  integrated  analytically.  The  parameter  £re^ 

provides  an  alternative  basis  for  increasing  the  step  size, 
based  on  the  average  relative  error  in  F  calculated  from  its 
second  derivative.  The  scaling  parameter  a  sets  a  limit  on 
how  rapidly  step  size  can  increase. 


The  parameters  values  that  are  used  in  MIREM  are 


a 

6 

emin 

erel 

C1 


4 

0.025 

0.00001  hrs 
0.005 

0.025-MTBF 


Tests  indicate  that  the  MTBCF  accuracy  obtained  using  these 
values  is  better  than  0.5%,  while  an  average  of  only  22  func¬ 
tion  evaluations  was  required.  These  results  suggest  that  the 
algorithm  is  more  efficient,  for  the  life  distributions  con¬ 
sidered,  than  a  general-purpose  routine. 


A. 7  Imperfect  Switching 

The  previous  sections  have  assumed  that  the  system  con¬ 
troller  always  selects  a  configuration  in  which  the  relevant 
functions  are  available,  if  such  a  configuration  exists.  This 
perfect  switching  assumption  requires 

(1)  Perfect  Built-In  Test  (BIT)  fault 
isolation,  and 

(2)  Optimal  reconfiguration  logic  in  the 
controller . 
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Condition  (1)  will  now  be  relaxed  to  consider  undetected  fail¬ 
ures  and  false  alarms.  Let 


A..  =  )  1  if  branch  i  is  actually  operable 

1  10  o.w. 

A  =  [A.] 

B„.  =  /  1  if  branch  i  is  believed  operable  by  the  controller 

1  l  0  o.w. 

B  =  [B.] 

V  =  {possible  configurations} 

<!<(b)  =  the  configuration  selected  when  B  =  b,  i|>(b)  e  Y 

1  if  there  is  a  configuration  in  which  the  system 
is  up  when  A  =  a 

0  o.w. 

!1  if  the  configuration  makes  the  system  up 
when  A  =  a 

0  o.w. 


T  =  system  "life";  the  first  time  at  which  r(A,»|»(B))  =  0 
Tg  =  believed  system  life;  the  first  time  at  which  0(B)  =  0 


A  mission  of  length  t  can  have  six  outcomes,  with  proba¬ 
bilities  p-j.,  ...,  Pv^: 

I.  Up  and  Believed  Up:  T,  Tg  >  t.  At  time  t, 
f(A,  0(B))  =  1  and  $(B)  =  1- 


II.  Up  and  Believed  Down:  Tg  <  t  <  T.  At  time  t, 

T(A, 4<(B))  =  1  and  <J> (B)  =  0. 

III.  Down  and  Believed  Down:  T,  Tg  <  t  and,  at  time  t, 

4>(A)  =  0  (system  would  be  down  even  with  perfect  switch¬ 
ing).  At  time  t,  4>(B)  =  0. 

IV.  Down  and  Believed  Up:  T  <  t  <  Tg  and,  at  time  t, 

<j>(A)  =  0  (system  would  be  down  even  with  perfect 
switching).  At  time  t,  41(B)  =  1. 

V.  Wrong  Configuration  and  Believed  Down:  T,  Tg  <  t  and,  at 

time  t,  4>(A)  =  1  (system  would  be  up  with  perfect  switch¬ 
ing).  At  time  t,  41(B)  =  0.  At  some  time  in  [0,t], 

T  (A, 41(B))  =  0. 


VI. 


Wrong  Configuration  and  Believed  Ur 


<  t  <  Tg  and,  at 


time  t,  4>(A)  =  1  (system  would  be  up  with  perfect  switch¬ 
ing).  At  time  t,  41(B)  =1.  At  some  time  in  [0,t], 
r(A, 41(B))  =  0. 


These  six  events  are  mutually  exclusive  and  exhaustive; 
their  relationship  is  shown  in  Figure  A-l.  Reliability  of  the 
imperfect  switching  system  is 

mcspimp  =  PI  +  PII  (20) 


Reliability  of  the  perfect  switching  system, 


MCSPPERF  "  PI  +  PII  +  PV  +  PVI 


(21) 


can  be  evaluated  using  Section  A. 4.  If  the  mission  is  aborted 
when  the  system  is  believed  down,  mission  reliability  is  p^.. 

A. 7.1  False  Aborts 

A  mission  abort,  or  believed  failure,  occurs  without  an 
actual  system  failure  with  probability  Pjj-  First,  an  upper 
bound  for  p^j  will  be  derived. 
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Ill,  V 


IV,  VI 


Figure  A-l.  System  Life  Outcomes 


Define  the  additional  (0,1)  resource  status  vectors: 

=  latent  undetected  failures  at  time  t 

(branch  has  not  been  used  since  the  undetected 
failure) 

UM  =  manifest  undetected  failures  at  time  t 

(branch  has  been  used  since  the  undetected 
failure) 

U  =  +  -M  =  undetected  failures 

F  =  false  alarms 


Then 


B  =  A  -  U  +  F 


(22) 


Also  define 


H .  =  undetected  failure  rate  in  pool  i 


MB?  W 


a  .  = 


6  . 
1 


a 

a 

6 


false  alarm  failure  rate  in  pool  i 
detected  failure  rate  in  pool  i 

•n*i 


lSi> 


iatl 


=  ^ ^  Hi  *  (no  branches  in  pool  i) 


=  ^ ^  •  (no  branches  in  pool  i) 


£‘i  (k) 


pool  i  requirement  under  allocation  (of 
functions  to  chains)  k 


R,  (t)  =  reliability  of  perfect  switching  system 
at  time  t  with  pool  failure  rates 


Now,  since  event  II  can  occur  only  if  these  are  false  alarms, 


pu  =  Pr{TB  <  t  <  T} 


=  Pr{TR  <  t  and  F  /  0}  Pr{T  >  t  |  TR  <  t,  F  ?  0} 


B 


(23) 


Pr  {Tb  <  t  and  F  /  0}  =  Pr{Tg  <  t}  -  Pr{Tg  <  t  |  F  =  0}  Pr{F  =  0 


=  1  -  R„+6<t)  -  (1  -  Rs<t)]e 


■a  t 


(24) 


It  will  be  assumed  throughout  that  false  alarms  increase  the 
chance  of  mission  failure  since,  for  any  system,  some  allocation 


scheme  i|<  satisfies  this  assumption.  Then  the  second  term 
of  Equation  23  can  be  bounded  by 


Pr{T  >  t  |  Tg  <  t,  F  /  0)  <  Pr{T  >  t} 


<  Pr{T  >  t  |  F  =  0} 


=  Pr{«t>(A)  =  l,  UM  =  0  |  F  =  0} 
min  {Rg(t),  Pr{UM  =  0}} 


(25) 


The  probability  of  a  single  undetected  failure  being  used  during 
a  mission  is  at  least  as  great  as  the  probability  that  the 
branch  is  in  use  when  it  fails.  This  probability  may  depend 
on  the  allocation;  a  lower  bound  is 


min  p(£)  (26) 

allocations 
£ 


where  P<£>  =  FT  "  .  ri£ 

1  pools  X 


r.  =  pool  i  requirement  under  allocation  £ 


Hence , 


Pr{UM  =  0 


|U|  =  1}  <  1  -  P 


(27) 


Assuming  that  no  single  branch  dominates  the  undetected  failures 
(q  ^  <<  q),  a  Poisson  approximation  to  the  failure  process  will 

be  accurate: 


Pr{UM  =  0}  =  ^  Pr{|UMl  =  0  1  |U|  =  n} 
n=0 

Pr{|U|  =  n} 

00 

<  ^  (l-p)n  e"nt  (nt)n/n! 
n=0 

=  e-pnt 

(28) 

Combining  Equations  25  and  28, 

Pr{T  >  t  |  TB  <  t,  F  /  0}  <  min  {Rfi(t),  e‘pnt} 

(29) 

Additional  bounds  for  can  be  obtained  by  combining 

bounds  on  +  p^j  from  above  with  the  following  bounds  on  p^. 

Since  T  <  t  <  Tg  implies  U  /  0, 

Pj  =  Pr{T  >  t  and  Tg  >  t} 

>  Pr{Tg  >  t}  Pr{U  =  0} 

\+6^ e 

(30) 

Also,  using  Equation  28, 

Pj  =  Pr{Tg  >  t}  Pr{UM  =  0  |  Tg  >  t} 

<  W°  e‘PnC 

(31) 

A. 7. 2  Mission  Failures 

The  contribution  of  imperfect  switching  to 
is  MCSPppp„  -  MCSPtmp.  Approximate  bounds  are 

mission  failures 

mcspimp  =  Pr{T  >  t} 

<  Pr{T  >  t  |  F  =  0} 

=  Rfi(t)  Pr{UM  =  0  |  <t>  (A-U)  =  1,  F  =  0} 

<  R6(t)  e'pnt  (32) 

and 

MCSPIMp  =  Pr{ T  >  t  |  F  =  0} 

>  Rg(t)  Pr{ U  =  0} 

=  Rfi(t)  e'nt  (33) 


MCSPpERp  is  known  exactly;  it  is  just  R^+^(t). 


A. 8  Repair  Policies 

In  this  section,  the  analysis  is  extended  to  consider 
repair.  Four  repair  policies  are  considered: 

1.  Immediate  Repair  -  repair  all  faults  at  the  end  of 
each  mission. 

2.  Deferred  Repair  -  repair  when  a  critical  failure  occurs 

3.  Scheduled  Maintenance  -  repair  after  a  specified  oper¬ 
ating  time  or  when  a  critical  failure  occurs. 

4.  Repair  at  Degraded  Level  -  repair  when  the  number  of 
branches  available  in  some  pool  falls  below  a  specified  minimum. 


The  MCSP  calculation  of  Sections  A. 3  and  A. 4  assumes  that  the 
system  is  fully  repaired  at  the  beginning  of  the  mission;  this 
is  consistent  with  immediate  repair.  The  MTBCF  calculation  of 
Section  A. 5  assumes  that  no  repair  occurs  before  critical  fail¬ 
ure;  this  is  consistent  with  deferred  repair.  For  each  repair 
policy,  the  following  additional  quantities  will  be  derived: 


Also,  because  a  system  composed  of  constant  failure  rate  compo¬ 
nents  has  an  increasing  failure  rate,  the  rate  of  critical 
failure  goes  down  after  one  occurs  and  the  system  is  repaired. 
Therefore,  the  probability  of  two  or  more  critical  failures  is 
bounded  above  by  a  Poisson  distribution  with  rate  -In  MCSP. 
Because  the  rate  parameter  is  also  the  mean, 

MTBCF  >  t/( -In  MCSP)  (34) 


It  can  be  shown  that  Equation  34  is  accurate  to  within  t,  re 
gardless  of  when  failures  occur  within  a  mission.  It  will  be 

used  to  relate  MTBCF  and  MCSP. 

A. 8.1  MTTR 
Let 

N_  =  number  of  failures  repaired  per 
maintenance  action 
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MTTR(j)  =  MTTR  of  resource  type  j 


nj  =  number  of  type  j  resources  in  the  system 
X.  =  failure  rate  of  resource  j 

•J 

MTBF  =  mean  time  between  failure,  critical 
or  noncritical 

MTTRRES  =  average  resource  MTTR. 

Neglecting  standby  pools  and  unrepaired  failures, 


MTBF  =  (V]  n,  X.)"1 

J  J 

j 

(35a) 

MTTRrps  =  MTBF  *  ^  nj  Xj  MTTR(j) 

j 

(35b) 

E[Np]  =  MTBMA/MTBF 

(35c) 

Under  a  series  repair  concept  (one  repairman),  there  is 
no  availability  payoff  for  the  deferral  of  repairs  (except  for 
the  second-order  effect  of  a  reduced  number  of  failures,  which 
is  neglected  below): 


MTTR  =  E [Np ]  MTTRres 

=  MTBMA  (MTTRres)/MTBF  (36a) 


MTBMA 

I  "  MTBMA  +  MTTR 


MTBF 

MTBF  +  MTTRDrc 


(36b) 


To  analyze  a  parallel  repair  concept  (unlimited  re¬ 
pairmen),  let 

F(t)  =  distribution  function  of  MTTR  for  one 
resource  failure 


The  system  repair  time  is  the  maximum  of  the  repair  times  for 
the  failed  resources.  Given  the  number  of  failures,  the  mean 
(MTTR)  can  be  approximated  as  a  percentile  of  the  distribution 
function  F(t);  that  is,  MTTR  satisfies 

F (MTTR)  =  a  (37) 

for  some  percentile  0  <  a  <  1.  A  "typical,"  uniform  distribution 
of  Np  failures  gives  percentiles  of  l/(Np+l),...  Np/(Np+l); 

i.e.,  a  maximum  of  Np/(Np+l).  In  principle,  one  could  take 

the  expectation  of  MTTR  over  Np  using  this  percentile.  For 

simplicity,  interpolate  and  use 

a  =  E(Np)  /[E(Np)-l ]  (38) 

in  Equation  37  to  approximate  MTTR. 

A. 8. 2  Immediate  Repair 

Under  immediate  repair  MCSP  =  MCSP  (calculated  in  Sec¬ 
tions  A. 3  and  A. 4).  Also,  MTBMA  =  MTBF  since  all  failures  are 
repaired . 

A. 8. 3  Deferred  Repair 

Under  deferred  repair,  MTBCF  is  computed  using  Sec¬ 
tion  A.  6  and  converted  to  MCSP  using  Equation  34.  Also, 

MTBMA  =  MTBCF  since  only  critical  failures  are  repaired. 

A. 8.4  Scheduled  Maintenance 

For  scheduled  maintenance,  let 

T^j  =  operating  time  between  scheduled  maintenance 

nM  =  P*Vj/t  1  =  num^er  missions  between  scheduled 
maintenance 


[xl  =  smallest  integer  greater  than  or  equal  to  x. 


t  =  operating  time  at  which  critical  failure 
occurs 

ti  =  E{t  |  (i-1)  t  <  t  <  it] 


By  conditioning  on  when  critical  failure  occurs  and  recognizing 
that  the  system  is  reset  (repaired)  at  n^  t,  one  can  write 


nM 

MTBCF  =  xi[MCSP((i-l)t)  -  MCSP(it)]  +  MCSP(nMt )  (nMt  +  MTBCF ) 
i=l 

(39) 

Using  the  approximation  T  ^  =  (i-%)t  gives 
nM-l 

MTBCF  =  ^  MCSP(it)  +  %  MCSP(nMt ) ]/[ 1  -  MCSP(nMt)] 

i=l 

(40) 


To  avoid  long  processing  times,  n^  is  limited  to  20  in  the 

M1REM  software.  When  T„  exceeds  20  missions,  the  interval  t 
in  Equation  40  is  adjusted. 

To  compute  MTBMA,  repair  is  viewed  as  a  renewal  process. 
Three  events  can  occur  at  renewal: 

CF :  a  critial  failure 

S:  scheduled  maintenance  when  there  are  no 

faults  to  repair 

R:  scheduled  maintenance  when  there  are 

repairs 
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Only  the  events  CF  and  R  are  counted  as  maintenance  actions. 
Let  denote  the  mean  operating  time  since  scheduled  main¬ 

tenance  at  which  CF  occurs.  The  total  rate  at  which  the  events 
CF  and  R  occur  is 


mtbma'1  =  MTBCF"1  + 


MTBCF-1  + 


_ _ Pr{R  at  renewal}  _ 

Pr{CF  at  renewal}  +  T^(l-Pr{CF  at  renewal}) 


MCSP(Tm)  -  e"TM/MTBF 

tcfu-mcsp(tm)]  +  tm  mcsp(tm) 


The  value  of  xCF  can  be  determined  from  the  rate  of  CF  events: 


MTBCF 


-1  . 


1  -  MCSP(Tm) 

t^fl  -  MCSP(Tw)  I  +  Tu  MCSP(T. 


tcf  =  MTBCF  -  Tm  MCSP(Tm)/(1  -  MCSP(TM)] 


(42) 


Combining  Equations  41  and  42  gives 


MTBMA  = 


MTBCF  [1-MCSP(Tm)) 


1  -  e 


-TM/MTBF 


(43) 


A. 8. 5  Repair  at  Degraded  Level 


For  repair  at  degraded  level,  let 


m^  =  repair  level  for  pool  i 


The  system  is  repaired  when  C^(t)  <  m^  for  some  pool  i.  The 

reliability  measures  MCSP  and  MTBCF  will  be  derived  only  for 

systems  with  series  chains  and  no  groups.  First,  note  that 

r.  <  m.  <  c  i.e.,  repair  must  occur  when  a  critical  fail 

i  —  i  —  max  ,1 

ure  occurs,  if  not  before.  Let 

Pi(xi|m)  =  Pr{Ci(t)  =  xi  |  C(t)  >  m} 


p^(x|m)  =  Pr{C(t)  =  x  |  C ( t )  >_  m}  ,  for  a  system 

with  a  steady-state  distribution  of  C(0). 


PFi(Xf)  =  Pr{C^(t)  <  r^  |  C^(0)  =  x^} ,  calculated  using 
Section  A. 3. 


Assuming  the  pool  failures  probabilities  are  relatively  small, 
their  higher-order  terms  will  be  dropped: 


MCSP  = 


y  p(xim)  y  u-pfcx^] 

r  <  x  <  m  pools 


y  p(x|m)  [1-  y  PF(xi)] 
r  c  x  <  m  pools 


y  y  p(x|m)  PFi(xi) 
pools  r  >  x  >  ra 


i  -  2  2  pi(xi|m>  PFi<xi> 

pools  x  =m 
i  i  i 


(44) 


•V  '-.■T- 


To  evaluate  p^(x^|m),  the  distribution  of  under  the 
repair  policy  m,  drop  the  pool  subscript  and  let 

Pj  =  P±< J lm) 

£  =  [Pj],  j  =  cmax>i .  mi  (decreasing  order) 

MTBMA.  =  MTBMA  for  this  repair  policy  neglecting 
1  pool  i  failures 

=  1/MTBMA.  =  repair  rate  without  pool  i 

K  1 

\  =  pool  i  branch  failure  rate 


Then  C(t)  can  be  represented  by  a  continuous- time  Markov  renewal 
process  if  renewals  (repairs)  due  to  failures  in  other  pools 
are  approximated  by  a  constant  rate  \R.  The  transition  inten¬ 


sity  matrix  on  the  states  (c  .  m)  for  active  redundant 

pools  is  maX 


■c  „  X 
max 


cmax^ 

"AR"(cmax"1)X 


^cmax-1^ 


\R+m\ 


-\R-(m+l)X  (m+l)A 

— A  R — mA 


(45) 


The  steady-state  distribution  of  C(t)  is  p;  it  satisfies 


Qt  £  =  0 


(46) 


which  can  be  written 


Pj  =  pj-i  (j_1  +  VX)/j’  j  =  W1 

p  =  l(Pc  _i  +  ...  +  Pm+i>(AR/A>  +  Pm(m  +  *RA>]/n 
max  max 


(47) 


J. 


For  standby  redundant  pools, 


Q  = 


and 


-rX 

kn 


V rA 


rX 

■XR-rX 


rX 


rX 

-XR-rX 


(48) 


p.  =  pm[l  +  Xp/(r  X)]J_m,  j  =  m  +  1,...,  cmav-l 


max 


P„  =  t(p„  _i  +  •••  +  Pm+i>XR/*-  +  Pm<r  +  *RA)]/r 


max 


cmax~l 


(49) 


Equation  47  or  Equation  49  can  be  used  to  recursively  compute  p 
given  the  normalization  condition  Pm  +  • • •  +  Pc  =  1 • 

max 

MTBMA  can  be  computed  for  systems  with  series  or  parallel 
chains.  For  consistency  with  the  single  utilization  rates 
entered  for  type  S  pool  pairs,  MIREM  uses  a  single  repair 
level  m.  for  a  type  S  pool  pair.  It  is  allocated  to  the  indi¬ 
vidual  pools  as  min{m./2,  c  .}.  The  MTBCF  calculation  of 

l  max ,  l 

Section  A. 6  is  then  performed,  treating  all  chains  as  series 
chains  and  using  pool  requirements  of  m.  This  MTBCF  is  MTBMA 
for  the  repair  policy  m. 


A. 9  Other  Outputs 

Several  other  quantities  can  be  computed  by  MIREM.  The 
MTBFF  for  function  j  is  computed  in  the  same  manner  as  MTBCF 
using  j  as  the  only  critical  function;  i.e.,  F^  =  {j}  and  m=l. 

The  contribution  of  each  LRM/LRU  to  reliability  and  mainte 
nance  actions  can  also  be  computed.  Define  the  quantities 

Py.(t)  =  Pr{mission  success  at  t  |  no  failures 
n  in  LRU  h} 


q^t)  =  Pr{mission  success  at  t  discouting  LRU  h 
u  failures  |  mission  failure  by  t} 


MCSP(T;t)  =  Pr{mission  success  at  t  |  mission  success 
at  t  -  T} 

A^  =  total  failure  rate  in  LRU  h 

F^(t)  =  Pr{no  faults  in  LRU  h  at  time  t} 

r,(T;t)  =  Pr{ fault  in  LRU  h  at  time  t  |  mission  failure 
*  between  t  -  T  and  t} 


Then,  neglecting  standby  redundancy, 
Ph(t)  =  exp  (- Aht) 


(50) 


To  compute  p^(t),  the  failure  rates  X  in  Equation  4  are  set  to 

zero  for  pools  in  LRU  h;  MCSP  calculated  under  these  conditions 
is  equal  to  ph(t).  Then 


1  ■  ph(t> 
~  1  '  1  -  MCSP 


(51) 


The  MCSP  over  a  mission  of  length  T  for  a  system  that  has  oper¬ 
ated  t  -  T  hours  without  repair  is 

MCSP(T ; t)  =  MCSP( t )/MCSP( t  -  T)  (52) 

The  last  quantity  of  interest  is  r^(T;t),  the  probability  of 
removing  LRU  h  upon  repair  after  an  operating  time  of  t: 

lPh(t  -  T)  -  Ph(t)]F,(t) 
rh(T;t)  =  1  MCSP( t  -  T)  -  MCSP(t) 
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Please  enter  the  name  of  the  Architecture  File  to  be  read.  1»filename 
Or  enter  a  command :<H>ELP,  <E>XPLAIN,  <C>ONTINUE.  <B>ACK,  <Q>UIT 


ARCHITECTURE  PILE  MENU 


•»  .k  i 


Which  type  of  doto  do  you  wish  to  work  on? 

Index  Selection  Dependencies  Number 


1 .  Funct ions  None  5 

2.  LRVs/LRUa  None  3 

3.  Resources  None  1 

4.  Chains  Functions  2 

5.  Pools  Functions,  LRMs/LRUs,  Resources,  and  Chains  1 

6.  Save  Not  Applicable  - 

Please  enter  the  index  corresponding  to  your  selection. 

Or  enter  a  commond:<H>ELP,  <E>XPLAIN,  <B>ACK,  <Q>UIT 


Index  Function 


FUNCTION  LIST 
Index  Function 


PAGE  1  OF  2 


Index  Function 


Please  enter  the  command: 

i ndex«va 1 ue 

i ndex»va 1 ue ,  ... 

Or  enter  a 

command : <H>ELP , 

<E>XPLAIN, 

<C>ONTINUE,  <B>ACK,  <0>UIT 

4«f cn4 

FUNCTION  LIST 

PAGE  1  OF  2 

Index 

Function 

Index 

Function  Index 

Funct i on 

1  . 

FUNC1 

2. 

FCN2  3 . 

FCN3 

•  4. 

FCN4 

5. 

FCN5  6 . 

7. 

8. 

9. 

10. 

11  . 

12. 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20. 

21  . 

22. 

23. 

24. 

25. 

26. 

27. 

28. 

29. 

30. 

31  . 

32. 

33. 

34. 

35. 

36. 

37. 

38. 

39. 

Please  enter  the  command: 

i ndex»vo 1 ue , 

i ndex*vo 1 ue ,  ... 

Or  enter  a 

command :<H>ELP, 

<E>XPLA  IN , 

<C>ONTINUE.  <B>ACK ,  <Q>UIT 

E 


ARCHITECTURE  FILE  MENU 


Which  type  of  dato  do  you  wish  to  work  on? 
Index  Selection  Dependencies 


Number 


1 . 

Funct i ons 

None 

5 

2. 

LRMs/LRUs 

None 

3 

3. 

Resources 

None 

1 

4. 

Cha i ns 

Func  t i ons 

2 

5. 

Pool  s 

Functions,  LRMs/LRUs,  Resources,  and  Choi  ns 

1 

6. 

Save 

Not  Appl i cable 

- 

Pleose  enter  the  index  correspond! ng  to  your  selection. 
Or  enter  a  command : <H>ELP .  <£>XPLAIN.  <B>ACK.  <Q>UIT 


Index  LRM/LRU  Name 


LRM/LRU  CIST 
Index  LRM/LRU  Name 


PAGE  1  OF  6 


Index  LRM/LRU  Name 


1  .  LRM1 

2.  LRU1 

3. 

4. 

5. 

6 

7. 

8. 

9. 

10. 

11 . 

12. 

13. 

14. 

15. 

16. 

17. 

18. 

19. 

20. 

21 . 

22. 

23. 

24. 

25. 

26. 

27. 

28. 

29. 

30. 

31  . 

32. 

33. 

34. 

35. 

36. 

37. 

38. 

39. 

ise  enter  the  command: 

index-value,  index-value,  . 

Or  enter  a  command :<H>ELP.  <E>XPLAIN.  <C>ONTINUE,  <B>ACK,  <0>UIT 
4—1 rm2  5“ I ru3 


■r  ^  -  •  •  •  •  o 


Index  LRM/LRU  Name 


LRM/LRU  LIST 
Index  LRM/LRU  Nome 
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Index  LRM/LRU  Name 


1 . 

LRM1 

2. 

LRU1 

3 

•  4. 

LRM2 

•  5. 

LRU3 

6 

7. 

8. 

9 

10. 

11  . 

12 

13. 

14. 

15 

16. 

17. 

18 

19. 

20. 

21 

22. 

23. 

24 

25. 

26. 

27 

28. 

29. 

30 

31 . 

32. 

33 

34. 

35. 

36 

37. 

38. 

39 

LRU2 


Please  enter  the  command:  index-value,  index-value.  ... 

Or  enter  a  command :<H>ELP.  <E>XPLAIN,  <C>ONTINUE,  <B>ACK,  <Q>UIT 


ARCHITECTURE  FILE  MENU 
Which  type  of  data  do  you  wish  to  work  on? 


Index  Selection  Dependencies  Number 


1  .  Funct i ons  None  5 

2.  LRMs/LRUs  None  5 

3.  Resources  None  1 

4.  Chains  Functions  2 

5.  Pools  Functions.  LRMs/LRUs,  Resources,  and  Chains  1 

6.  Save  Not  Applicable  - 


Please  enter  the  index  corresponding  to  your  selection. 
Or  enter  a  command :<H>ELP .  <E>XPLAIN.  <B>ACK .  <0>UIT 


RESOURCE  LIST 

Res.  Failure  Change/ 

Index  No.  Qty  Rate  R/I  MTTR  Resource  Name  Delete 


1.  1  1  5  R  1.00  L-BAND  RECEIVER 

NOTE:  R  -  Resource,  I  -  Interconnection 
MTTR  -  Mean  Time  To  Repair  (hours) 

Please  enter  the  command:  index— value,  index— value,  ... 

(values  are  'c'  for  Change  and  'd’  for  Delete) 

Or  enter  a  command : <H>ELP ,  <E>XPLAIN,  <C>ONTINUE,  <A>DD .  <B>ACK ,  <Q>UIT 


RESOURCE  LIST 

Res.  Foi lure 

Index  No.  Qty  Rote  R/I  MTTR  Resource  Nome 


•1.  1  1  5  R  1.00  L-BAND  RECEIVER 


Chonge/ 
Oe I ete 


NOTE:  R  -  Resource,  I  -  Interconnection 
MTTR  «  Meon  Time  To  Repoir  (hours) 

Please  enter  the  command:  index-value,  index-value,  ... 

(values  are  'o'  for  Change  and  'd‘  for  Delete) 

Or  enter  a  command : <H>ELP,  <E>XPLAIN,  COONTINUE.  <A>DD .  <B>ACK,  <Q>UIT 


RESOURCE  DATA  ENTRY 


Index  Parameter 


Current  Value 


1 .  Resource  Number  1 

2.  Quantity  1 

3.  Failure  rate  (x  E-6  Hours)  5 

4.  Resource  or  Interconnect i on  (R  or  I)  R 

5.  Mean  time  to  repair  (hrs)  1.00 

6.  Resource  Name  L-BAND  RECEIVER 

Please  enter  the  command:  index-value,  index-value,  ... 

Or  enter  a  command : <H>ELP .  <E>XPLAIN,  <C>ONTINUE,  <B>ACK,  <Q>UIT 


2-2  3-10 


Index  Parameter 


RESOURCE  DATA  ENTRY 


Current  Value 


1  .  Resource  Number  1 

•2.  Quantity  2 

•3.  Failure  rate  (x  E-6  Hours)  10 

4.  Resource  or  Interconnection  (R  or  I)  R 

5.  Mean  time  to  repair  (hrs)  1.00 

6.  Resource  Nome  L-BAND  RECEIVER 

P lease  enter  the  command:  index-value,  index-value,  ... 

Or  enter  a  command :<H>ELP ,  <E>XPLAIN,  <C>ONTINUE,  <B>ACK,  <Q>UIT 


RESOURCE  LIST 

Res .  Failure 

Index  No.  Qty  Rate  R/I  MTTR  Resource  Nome 
1.  1  2  10  R  1.00  L-BAND  RECEIVER 


Change/ 

Delete 


NOTE:  R  -  Resource,  I  -  Interconnection 
MTTR  «  Mean  Time  To  Repoir  (hours) 


r 


IBHIWHWrT 


I  TW’I  ll'.l U  M  M TO W "J  '±  *x "-M ■->  »■>  ^ 


I 


I 


I 


ARCHITECTURE  FILE  MENU 
Which  type  of  doto  do  you  wish  to  work  on? 


Index  Selection  Dependencies  Number 


1 .  Funct i ons  None  5 

2.  LRMs/LRUs  None  5 

3.  Resources  None  1 

4.  Choins  Functions  2 

5.  Pools  Functions.  LRMs/LRUs.  Resources,  ond  Choins  1 

6.  Sove  Not  Applicable  - 


Please  enter  the  index  corresponding  to  your  selection. 
Or  enter  a  command : <H>ELP ,  <E>XPLAIN,  <B>ACK,  <Q>UIT 


4 


CHAIN  LIST 


Para  I  lei 

Index  Chain  Number  Chain  Number  Chain  Pair  Nome 


Change/ 

Delete 


1.  1  None  SERIES  CHAIN 

2.  2  3  PARALLEL  CHAIN 

Please  enter  the  command:  index-value.  index-value,  ... 

(values  are  *c’  for  Change  and  'd'  for  Delete) 

Or  enter  o  command :<H>ELP.  <E>XPLAIN,  <C>ONTINUE.  <A>DD .  <B>ACK,  <Q>UIT 

1-c  2-c  c 


CHAIN  DATA  ENTRY 


Index 

Parameter 

Current  Value 

1 . 

Chain  Number 

1 

2. 

Parallel  Chain  Number 

3. 

Chain  Name 

SERIES  CHAIN 

Please  enter  the  command:  index— value,  index-value.  ... 

Or  enter  a  command : <H>ELP .  <E>XPLAIN,  <C>ONTINUE,  <B>ACK,  <QMJIT 

c 

FUNCTIONS  IN  CHAIN  NUMBER  1 
Index  Funct i on 


•1 .  FUNC1 
2 .  FCN2 
•3.  FCN3 
4 .  FCN4 
•5.  FCN5 

NOTE:  The  asterisk  ('•')  indicates  functions  selected. 

Please  enter  the  command:  index  to  select  or  -index  to  delete. 

Or  enter  a  command : <H>£LP ,  <E>XPLAIN,  <C>ONTINUE,  <B>ACK .  <0>UIT 
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2 


FUNCTIONS  IN  CHAIN  NUMBER  1 


i 

t 


I 

I 

I 

i 


! 


Index  Function 


•1.  FUNC1 
*2.  FCN2 
*3 .  FCN3 
4 .  FCN4 
*5.  FCN5 

NOTE:  The  asterisk  (’•')  indicates  functions  selected. 

Please  enter  the  command:  index  to  select  or  -index  to  delete. 

Or  enter  a  command :<H>ELP,  <E>XPLAIN.  <C>ONTINUE.  <B>ACK,  <QXJIT 


CHAIN  DATA  ENTRY 


Index  Parameter  Current  Volue 


1 . 

Chain  Number 

2 

2. 

Parallel  Chain  Number 

3 

3. 

Cha i n  Name 

PARALLEL  CHAIN 

Please  enter  the  command:  index»value.  index-value.  ... 

Or  enter  a  command :<H>ELP .  <E>XPLAIN,  <OONTINUE,  <B>ACK ,  <Q>UIT 


FUNCTIONS  IN  CHAIN  NUMBER  2 
Index  Function 


•1.  FUNC1 
•2.  FCN2 
•3 .  FCN3 

4 .  FCN4 

5 .  FCN5 

NOTE:  The  asterisk  (’*’)  indicates  functions  selected. 

Please  enter  the  command:  index  to  select  or  -index  to  delete. 

Or  enter  a  command : <H>ELP ,  <E>XPLAIN.  <C>ONTINUE.  <B>ACK ,  <Q>UIT 


FUNCTIONS  IN  CHAIN  NUMBER  3 


Index  Function 


•  1  . 

FUNC1 

•  2. 

FCN2 

•  3. 

FCN3 

4. 

FCN4 

5. 

FCN5 

NOTE:  The  asterisk  ('•')  indicates  functions  selected. 

Please  enter  the  command:  index  to  select  or  -index  to  delete. 

Or  enter  a  command : <H>ELP ,  <E>XPLAIN.  <C>ONTINUE.  <B>ACK.  <Q>UIT 


CHAIN  LIST 

Paral lei 

Index  Chain  Number  Chain  Number  Chain  Pair  Name 


Change/ 

Delete 


1.  1  None  SERIES  CHAIN 

2.  2  3  PARALLEL  CHAIN 

Please  enter  the  command:  index-value.  index-value,  ... 

(values  are  ‘c‘  for  Change  and  ’d*  for  Delete) 

Or  enter  a  command :<H>ELP,  <E>XPLAIN,  <C>ONTINUE.  <A>OD,  <B>ACK.  <Q>UIT 

c 

ARCHITECTURE  PILE  MENU 
Which  type  of  data  do  you  wish  to  work  on? 

Index  Selection  Dependencies  Number 

1.  Functions  None  5 

2.  LRMs/LRUs  None  5 

3.  Resources  None  1 

4.  Chains  Functions  2 

5.  Pools  Functions,  LRMs/LRUs,  Resources,  and  Chains  1 

6.  Save  Not  Appl i cable  - 

Please  enter  the  index  correspond! ng  to  your  selection. 

Or  enter  a  command : <H>ELP ,  <E>XPLAIN,  <B>ACK,  <0>UIT 


Pool  Chain 

Index  No.  No.  Lrm/Lru  Name 
1.  1  2  LRU1 


POOL  LIST 


Pool  Type 


No.  of  Resource 
Branches  Numbers  A/S  C/R/D 


Noncontendi ng 


Please  enter  the  command:  index— value,  index— value,  ... 

(values  are  'c'  for  Change,  'r'  for  Repeat,  and  'd*  for  Delete) 

Or  enter  a  command :<H>ELP,  <E>XPLAIN,  <C>ONTINUE.  <A>OD,  <B>ACK,  <Q>UIT 


POOL  LIST 


Pool  Chain 

Index  No.  No.  Lrm/Lru  Name 
•  1  .  1  2  LRU1 


Pool  Type 
Noncont end i ng 


No.  of  Resource 
Branches  Numbers  A/S  C/R/D 


Please  enter  the  command:  index-value,  index-value,  ... 

(values  ore  'c'  for  Change,  'r‘  for  Repeat,  and  'd'  for  Delete) 

Or  enter  a  command :<H>ELP,  <E>XPLAIN,  <C>ONTINUE,  <A>DD,  <B>ACK.  <Q>UIT 
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POOL  LIST 


Pool 
Index  No. 

Chain 

No.  Lrm/Lru  Nome 

Pool  Type 

No.  of  Resource 

Branches  Numbers 

A/S  C/R/D 

1  .  1 

2.  1 

2  LRU1 

3  LRU1 

Noncontend i ng 
Noncontend i ng 

1  1 

1  1 

A 

A 

Please  enter  the  command:  index-value,  index-value,  ... 

(values  are  ‘c‘  for  Change,  *r*  for  Repeat,  and  ’d’ 
Or  enter  a  command :<H>ELP ,  <E>XPLAIN.  <C>ONTINUE,  <A>DD, 

for  Delete) 

<B>ACK ,  <Q>UIT 

2-d  c 

POOL  LIST 

Pool 
Index  No. 

Cha  i  n 

No.  Lrm/Lru  Name 

Pool  Type 

No.  of  Resource 
Branches  Numbers 

A/S  C/R/D 

t .  1 

2  LRU1 

Noncontendi ng 

1  1 

A 

Please  enter  the  command:  index-value,  index-value,  ... 

(values  are  'c‘  for  Change,  ’r’  for  Repeat,  and  ’d* 
Or  enter  a  command :<H>ELP,  <E>XPLAIN,  <C>ONTINUE,  <A>DD . 

for  Delete) 

<B>ACK,  <Q>U I T 

1-r 

POOL  LIST 

Pool 
Index  No. 

Cha  i  n 

No.  Lrm/Lru  Name 

Pool  Type 

No.  of  Resource 

Branches  Numbers 

A/S  C/R/D 

•  1  .  1 

2  LRU1 

Noncontending 

1  1 

A  R 

Please  enter  the  command:  index-value,  index-value.  ... 

(values  ore  ’c'  for  Change,  *r*  for  Repeat,  and  ’d'  for  Delete) 

Or  enter  a  command :<H>ELP.  <E>XPLAIN,  <C>ONTINUE.  <A>DD .  <B>ACK.  <Q>UIT 


c 

POOL  DATA  ENTRY 

Index  Parameter  Current  Value 


1  . 

Pool  Number 

1 

2. 

Chain  Number 

3. 

LRM/LRU  Name 

LRUt 

4. 

Pool  Type  ( ’N’ ,  ’C‘ 

,  ’S’  ,  'F')  N 

5. 

Number  of  Branches 

t 

6. 

Active/Standby  ('A' 

'  or  ’S')  A 

7. 

Undetected  Fai lure 

Rate  0.010 

8. 

False  Alarm  Rate 

0.050 

9. 

Min  accpt  level  of 

repair  1 

NOTE:  (4).  ’N’  is  Noncontending,  ’C’  is  Contending,  ‘S’  is  Shored,  and 
’ F ’  is  Cho i n— Fa i I . 

Please  enter  the  command:  index— value,  index-value,  ... 

Or  enter  a  command : <H>ELP,  <E>XPLAIN,  <C>ONTINUE.  <B>ACK,  <0>UIT 


2< 


POOL  DATA  ENTRY 


Ind«x  Porometer 


1 .  Pool  Number 
*2.  Chain  Number 

3 .  LRM/LRU  Nome 

4.  Pool  Type  (’N’ .  ’C’  ,  ‘S' .  1 

5.  Number  of  Branches 

6.  Act i ve/St ondby  ('A'  or  ’S') 

7.  Undetected  Failure  Rate 

8.  False  Alarm  Rate 

9.  Min  accpt  level  of  repair 


Current  Value 

1 

3 

LRU1 

N 

1 

A 

0.010 

0.0S0 

1 


NOTE:  (4).  ’N’  is  Noncontending, 
’F*  is  Cbain-Fai I . 


'C'  is  Contending,  ‘S’  is  Shared,  and 


Please  enter  the  command:  index— value,  index-value,  ... 

Or  enter  a  command :<H>ELP,  <E>XPLAIN,  <C>ONTINUE.  <B>ACK,  <Q>UIT 


POOL  RESOURCES  FOR  POOL  NUMBER  1  PAGE  1  OF  2 

Index  Resource  Name  Resource  Number 


1 . 
2. 

3. 

4. 

5. 

6. 

7. 

8. 
9. 

10. 
11  . 
12. 
13. 


L-BANO  RECEIVER 


1 


Please  enter  the  command:  index— value,  index— value.  ... 

Or  enter  a  command :<H>ELP ,  <E>XPLAIN,  <P>AGEn,  <C>ONTINUE,  <B>ACK.  <Q>UIT 


I 


ft 


L! 

V. 


i 

y": 


UTILIZATION 

RATES  FOR 

POOL  NUMBER  1 

>.V 

y.y 

Index 

Funct ion 

Rate 

1  . 

FUNC1 

1 .00 

2. 

FCN2 

0.00 

Pi 

3. 

FCN3 

0.00 

4. 

FCN4 

0.00 

5. 

FCN5 

0.00 

Please  enter  the  command:  index-value,  index-value,  ... 

V.- 

Or  enter  a  command : <H>ELP .  <E>XPLAIN,  <C>ONTINUE,  <B>ACK,  <Q>UIT 

1-0  2-1 
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UTILIZATION  RATES  FOR  POOL  NUMBER  1 
Index  Function  Rate 


*1 . 

FUNC1 

0.00 

•2. 

FCN2 

1  .00 

3. 

FCN3 

0.00 

4. 

FCN4 

0.00 

5. 

FCN5 

0.00 

Please  enter  the  command:  index-value,  index-value,  ... 

Or  enter  a  command :<H>ELP,  <E>XPLAIN,  <C>ONTINUE.  <B>ACK,  <Q>UIT 

c 

POOL  LIST 


Pool  Chain  No.  of  Resource 

Index  No.  No.  Lrm/Lru  Name  Pool  Type  Branches  Numbers  A/S  C/R/0 


1.  1  2  LRUt  Noncontending  11  A 

2.  1  3  LRU1  Noncontending  1  1  A 

Please  enter  the  command:  index-value,  index-value,  ... 

(values  are  'c'  for  Change,  *r*  for  Repeat,  and  ’d'  for  Delete) 

Or  enter  a  command :<H>ELP.  <E>XPLAIN,  <C>ONTINUE.  <A>OD,  <B>ACK,  <0>UIT 

c 

ARCHITECTURE  FILE  MENU 
Which  type  of  data  do  you  wish  to  work  on? 


Index  Selection  Dependencies  Number 


1 .  Funct i ons  None  5 

2.  LRMs/LRUs  None  5 

3.  Resources  None  1 

4.  Chains  Functions  2 


5.  Pools  Functions,  LRMs/LRUs,  Resources,  and  Chains  2 

6.  Save  Not  Applicable  - 

Please  enter  the  index  corresponding  to  your  selection. 

Or  enter  a  command : <H>ELP ,  <E>XPLAIN,  <B>ACK ,  <Q>UIT 


6 


ARCHITECTURE  FILE  NAME 


Index  Description  Current  Value 


1 .  Archi tecture  Fi le 

Please  enter  the  name  of  the  Architecture  File  to  be  created.  1-filename 
Or  enter  a  command : <H>ELP ,  <E>XPLAIN,  <C>ONTINUE.  <B>ACK,  <Q>UIT 


1-arehout  c 


RUN  IDENTIFIER 


A  Run  Identifier  is  placed  at  the  top  of  each  printout 
diet  inguishing  results  front  various  runs.  It  contains 


page  as  a  means  of 
up  to  72  characters. 


Index  Run  Identifier 


•1.  SCENARIO  FILE  EDITING  TEST2 

Please  enter  the  Run  Identifier.  1»'run  identifier' 
Or  enter  a  command :<H>ELP,  <C>ONTINUE.  <B>ACK,  <G>UIT 


COMPUTATION  SELECTION  MENU 

Which  do  you  wish  to  compute?  : 

•1.  MCSP  And  Pool/Chain  Budget;  Immediate  Repair  MTBCF 

*2.  Phase-By-Phase  MCSP 

•3.  MTBCF 

•4.  MTBFF 

•5.  LRM/LRU  Budget 

•6.  Repair 

•7.  BIT  Effectiveness 
*8.  Full  BIT  Effectiveness 

NOTE:  MCSP  -  Mission  Completion  Success  Probability 
MTBCF  -  Mean  Time  Between  Critical  Failures 
MTBFF  -  Mean  Time  Between  Function  Failures 

NOTE:  The  asterisk  ('•’)  indicates  functions  selected. 


Please  enter  the  command:  index  to  select  or  -index  to  delete. 

Or  enter  a  command : <H>ELP .  <E>XPUIN.  <C>ONTINUE.  <B>ACK.  <0>UIT 

-2  -5 

COMPUTATION  SELECTION  MENU 

Whieh  do  you  wish  to  compute?  : 

•  1.  MCSP  And  Poo  I /Chain  Budget:  Immediate  Repair  MTBCF 
2.  Phase-By-Phase  MCSP 
•3.  MTBCF 
•4.  MTBFF 
5.  LRM/LRU  Budget 
•6.  Repair 

•7.  BIT  Effectiveness 
•8.  Full  BIT  Effectiveness 

NOTE:  MCSP  -  Mission  Completion  Success  Probability 
MTBCF  -  Mean  Time  Between  Criticol  Failures 
MTBFF  -  Mean  Time  Between  Function  Failures 

NOTE:  The  asterisk  ('•')  indicates  functions  selected. 

Please  enter  the  command:  index  to  select  or  -index  to  delete. 

Or  enter  a  command :<H>ELP.  <E>XPLAIN,  <C>ONTINUE.  <B>ACK.  <0>UIT 


c 
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PLOT  SELECTION  MENU 


Which  do  you  wish  to  plot?  : 

*1.  MCSP  And  Poo  I /Chain  Budget;  Immediate  Repair  MTBCF 

2.  Phose-By-Phase  MCSP 

3 .  MTBCF 

4.  MTBFF 

5.  LRM/LRU  Budget 

6.  Repair 

NOTE:  MCSP  -  Mission  Completion  Success  Probability 
MTBCF  -  Mean  Time  Between  Critical  Failures 
MTBFF  -  Mean  Time  Between  Function  Failures 

NOTE:  The  asterisk  ('«’)  indicates  functions  selected. 

Please  enter  the  command:  index  to  select  or  -index  to  delete. 

Or  enter  a  command : <H>ELP .  <E>XPLAIN.  <C>ONTINUE.  <B>ACK.  <0>UIT 

3  6 

PLOT  SELECTION  MENU 


Which  do  you  wish  to  plot?  : 

•1.  MCSP  And  Pool/Choin  Budget;  Immediate  Repair  MTBCF 
2 .  Phase-By-Phase  MCSP 
•3.  MTBCF 

4 .  MTBFF 

5.  LRM/LRU  Budget 
•6 .  Repo i r 

NOTE:  MCSP  -  Mission  Completion  Success  Probability 
MTBCF  -  Mean  Time  Between  Critical  Failures 
MTBFF  -  Mean  Time  Between  Function  Failures 

NOTE:  The  asterisk  ('•’)  indicates  functions  selected. 

Please  enter  the  command:  index  to  select  or  -index  to  delete. 

Or  enter  a  command : <H>ELP ,  <E>XPLAIN,  <C>ONTINUE.  <B>ACK.  <Q>UIT 


c 

TOTAL  OPERATING  TIME  DATA  ENTRY 


I ndex  Func t i on 


1 .  1.00 

4 .  4.00 

7. 


Index  Function 


2.  1.50 

5. 


I ndex  Func t i on 


3 .  2.50 

6. 


Pleose  enter  the  command:  index»value.  index»value,  ... 

Or  enter  a  command : <H>ELP .  <E>XPLAIN.  <C>ONTINUE.  <B>ACK .  <Q>UIT 


TOTAL  OPERATING  TIME  DATA  ENTRY 


Index  Function 


Index  Funct i on 


Index  Function 


1.  1.00  2.  1.50  «3.  2.50 

4 .  4.00  5 .  6 . 

7. 

Please  enter  the  command:  index-value,  index-value,  ... 

Or  enter  a  command :<H>ELP ,  <E>XPLAIN,  <C>ONT I NUE ,  <B>ACK,  <Q>UIT 


c 

BASIC  SCENARIO  FILE  PARAMETERS 
Index  Parameter  Allowed  Values 


Current  Value 


1.  Processing  Option  Quick,  Full  FULL 

2.  Print  Architecture  File  Report?  Yes,  No  YES 

3.  Print  Intermediate  Results?  Yes,  No  NO 

4.  Functions  Required  Simultaneously?  Yes,  No  YES 

5.  Failure  Rate  Scale  Factor  Positive  Real  Number  1.00 

6.  Scheduled  Maintenance  (hours)  Positive  Real  Number  2.00 

7.  Repair  Sequence  Series  or  Parallel  P 


Please  enter  the  command:  index-value,  index-value,  ... 

Or  enter  a  command :<H>ELP ,  <E>XPLAIN,  <C>ONTINUE.  <B>ACK,  <Q>UIT 

1-quick  3-ves  4— no  6—2.5 

BASIC  SCENARIO  FILE  PARAMETERS 


Index  Parameter 


A I  lowed  Values 


Current  Value 


•  1 . 

Process i ng  Opt i on 

Ou i ck ,  Full 

QUICK 

2. 

Print  Architecture 

File  Report? 

Yes,  No 

YES 

•3. 

Print  Intermediate 

Resul ts? 

Yes,  No 

YES 

•  4. 

Funct i ons  Fequ i red 

Simul taneously? 

Yes,  No 

NO 

5. 

Failure  Rate  Sea  1 e 

Factor 

Positive  Real  Number 

1 .00 

•  6. 

Scheduled  Maintenance  (hours) 

Positive  Real  Number 

2.50 

7. 

Repair  Sequence 

Series  or  Parallel 

P 

Please  enter  the  command:  index-value,  index-value,  ... 

Or  enter  a  command :<H>ELP,  <E>XPLAIN,  <C>ONTINUE.  <B>ACK,  <Q>UIT 


c 

MISSION  PHASE  LIST 


Phase  Length 
Index  Number  (Hours) 


Phose  Name 


Critical  Change/ 
Funct ions  Delete 


1 .  1  0.33  FRONT  END 

2.  2  0.67  BACK  END 


1 

2 


Please  enter  the  command:  index— value,  index-value, 

(values  are  ’c'  for  Change  and  'd'  for  Delete) 

Or  enter  a  command : <H>ELP ,  <E>XPLAIN,  <C>ONTINUE,  <A>DD ,  <B>ACK,  <Q>UIT 

1  — c 


j 


123 


Please  enter  the  command:  index-value,  index— value,  ... 

(values  are  'c'  for  Change  and  'd‘  for  Delete) 

Or  enter  a  command : <H>ELP .  <E>XPLAIN.  <C>ONTINUE,  <A>DD ,  <B>ACK.  <Q>UIT 

c 

MISSION  PHASE  DATA  ENTRY 
Index  Parameter  Current  Value 


1.  Mission  Phase  Number  1 

2.  Mission  Phase  Length  (Hours)  0.23 

3.  Mission  Phase  Name  FRONT  END 

Please  enter  the  command:  index-value,  index-value,  ... 

Or  enter  a  command : <H>ELP .  <E>XPLAIN.  <C>ONTINUE.  <B>ACK.  <Q>UIT 

2-.  2 

MISSION  PHASE  DATA  ENTRY 
Index  Parameter  Current  Volue 


1.  Mission  Phase  Number  1 

•2.  Mission  Phase  Length  (Hours)  0.20 
3.  Mission  Phase  Name  FRONT  END 

Please  enter  the  command:  index-value,  index-value,  ... 

Or  enter  a  command :<H>ELP,  <E>XPLAIN.  <C>ONTINUE.  <B>ACK,  <Q>UIT 

c 

CRITICAL  FUNCTIONS  FOR  MISSION  PHASE  1 
Index  Function 


•1.  FUNC1 

2 .  FCN2 

3 .  FCN3 

4. 

5 .  FCN5 


NOTE:  The  asterisk  ('•')  indicates  functions  selected. 

Please  enter  the  command:  index  to  select  or  -index  to  delete. 

Or  enter  a  command : <H>ELP .  <E>XPLAIN,  <C>ONTINUE,  <B>ACK,  <0>UIT 


CRITICAL  FUNCTIONS  FOR  MISSION  PHASE  1 


I ndex  Func  t i on 


*1 . 

FUNC1 

2. 

FCN2 

•  3. 

4. 

FCN3 

5. 

FCN5 

NOTE:  The  asterisk  ('•’)  indicates  functions  selected. 

Please  enter  the  command:  index  to  select  or  -index  to  delete. 

Or  enter  a  command : <H>ELP .  <E>XPLAIN,  <C>ONTINUE.  <B>ACK .  <Q>UIT 

c 

MISSION  PHASE  LIST 


Phase 

Index  Number 


Length 

(Hours) 


Phase  Name 


Critical  Change/ 
Funct i ons  Delete 


1 .  1  0.20  FRONT  END 

2.  2  0.67  BACK  END 


2 

2 


Please  enter  the  command:  index-value.  index-value,  ... 

(values  are  ’c'  for  Change  and  ’d’  for  Delete) 

Or  enter  a  command : <H>ELP ,  <E>XPLAIN,  <C>ONTINUE,  <A>DD .  <B>ACK ,  <Q>UIT 


C 

SCENARIO  FILE  NAME 

Index  Description  Current  Value 

1 .  Scenar i o  File 

Please  enter  the  name  of  the  Scenario  File  to  be  created.  1-filename 
Or  enter  a  command : <H>ELP ,  <E>XPLAIN,  <C>ONTlNUE,  <B>ACK ,  <Q>UIT 


1-scenout  c 


DIALOGUE  SELECTION  MENU 


> 

l 


I 


Do  you  wish  to: 

1.  Create  the  Architecture  file  from  scratch. 

2.  Update  an  existing  Architecture  file. 

3.  Create  the  Scenario  file  from  scratch.  (Requires 

4.  Update  an  existing  Scenario  file 

Please  enter  the  index  corresponding  to  your  selection 
Or  enter  o  command : <H>ELP ,  <E>XPLAIN,  <C>UIT 


an  A rch i t ec t ure 


file) 


TERMINATION  SCREEN 


You  hove  requested  to  end  the  MIREM  Data  Entry  program  now  in  progress. 

To  stop  the  current  processing  just  enter  q  or  quit.  NOTE,  however,  that  this 
will  cause  any  changes  made  since  the  last  file  creation  to  be  lost. 

If  you  have  not  stored  the  most  recent  changes  mode,  but  wish  to  do  so, 
enter  c  or  continue  and  you  can  continue  processing  from  the  point  thot  this 
screen  was  entered.  After  you  hove  stored  the  file  being  edited,  you  moy  then 
terminate  the  program  safely  by  entering  q  or  quit  again. 

Please  enter  the  command :<C>ONT I NUE,  <Q>UIT 

q 


MESSAGE  SUMMARY:  MESSAGE  NUMBER  -  COUNT 

219  2 

OASD  123  DETACHED 


UNDETECTED  FAILURES: 


RESOURCE  DATA  SHEET 


System: _ 

Architecture  File  Name:. 


RESOURCE 

NO. 


RESOURCE  NAME 


Date:. 


Analyst:. 


R/l  MTTR  QUANTITY 


Page _ of. 


FAILURE 

RATE 


APPENDIX  D:  GLOSSARY 


BIT 

branch 

chain 

chain-fail 

pool 

chain  pair 

contending 

pool 


critical 

failure 

critical 

function 

failure 

resiliency 

function 

group 

GPS 

ICNIA 

LRM 

LRU 


Built-In  Test. 

A  simple  parallel  path  in  a  pool. 

A  set  of  pools  arranged  in  series.  Chains  are 
organized  into  a  series/parallel  structure. 

Also  type  F  pool.  A  pool  that,  upon  failure 
prevents  all  resources  in  a  chain  from  being 
used,  including  type  S  resources.  Chain- fail 
pools  are  utilized  in  a  noncontending  fashion. 

Two  parallel  chains.  Also  used  to  refer  to  a 
series  chain,  so  that  all  chains  can  be  indexed 
by  chain  pair. 

Also  type  C  pool.  A  pool  in  which  separate 
resources,  or  fractions  thereof,  must  be  allo¬ 
cated  to  each  function  using  the  pool. 

A  failure  that  causes  loss  of  a  critical  func¬ 
tion,  and  hence,  loss  of  mission  capability. 

A  function  that  is  required  during  a  mission 
phase.  Criticality  can  be  defined  in  terms 
of  mission  success,  survival ,  etc. 

MTBCF/MTBF,  a  measure  of  fault  tolerance. 

A  distinct  operational  capability  of  the  system 
Used  to  describe  system  requirements. 

A  k-of-n  structure  containing  other  groups  or 
pools . 

Global  positioning  system. 

Integrated  communication,  navigation  and  identi 
fication  avionics. 

Line  replaceable  module. 

Line  replaceable  unit. 
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MCSP 


MTBCF 

MTBF 

MTBFF 

MTBMA 

MTTR 

noncontend¬ 
ing  pool 

parallel 

chain 

phase 

pool 

pool  pair 

pool  type 

primary 

chain 

primary 

pool 

RBD 

resource 


Mission  completion  success  probability;  the 
probability  of  completing  a  mission,  or  any 
specified  time  of  operation,  without  a  critical 
failure . 

Mean  time  between  critical  failure. 

Mean  time  between  failure  (first  failure). 

Mean  time  between  function  failure,  for  an 
individual  function. 

Mean  time  between  maintenance  actions. 

Mean  time  to  repair. 

Also  type  N  pool.  A  pool  in  which  the  same 
resources  can  be  utilized  by  any  number  of 
functions . 

A  chain  in  parallel  with  another  chain;  functions 
are  allocated  to  one  of  the  two  chains. 

A  time  interval  within  a  mission;  different 
functions  are  required  in  each  phase. 

A  reliability  structure  consisting  of  one  or 
more  simple  parallel  branches. 

Two  type  C  or  S  pools,  one  in  each  chain  of  a 
parallel  chain  pair,  with  the  same  utilization 
rates  and  the  same  pool  number. 

The  manner  in  which  a  resource  pool  is  utilized 
by  functions:  noncontending  (N),  contending  (C), 
shared  (S)  or  chain-fail  (F). 

The  first  chain  in  a  chain  pair. 


The  pool  in  a  pool  pair  that  is  in  the  primary 
chain . 

Reliability  block  diagram. 

A  component  or  portion  of  the  system  that  fails 
as  a  unit  and  has  the  same  status  (faulty  or 
good)  with  respect  to  all  functions  that  can 
use  the  resource. 
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SDU 

secondary 

chain 

secondary 

pool 

series 

chain 

shared  pool 

SINCGARS 

SRU 

Subgroup 

UHF 

utilization 

rate 


Secure  data  unit. 

The  second  chain  in  a  parallel  chain  pair. 

The  pool  in  a  pool  pair  that  is  in  the  secon¬ 
dary  chain. 

A  chain  that  is  not  in  parallel  with  another 
chain;  it  is  in  series  with  all  other  chain 
pairs . 

Also  type  S  pool.  A  pool  in  a  parallel  chain 
that  shares  resources  with  its  counterpart  on 
the  other  chain  in  the  parallel  chain  pair. 
Shared  pools  are  utilized  in  a  contending 
fashion. 

Single-channel  ground  and  airborne  radio 
subsystem. 

Shop  replacable  unit. 

A  pool  or  group  contained  in  a  larger  group. 

Ultra-high  frequency  voice  communication. 

The  number  of  branches  in  a  pool  a  group  or  sub 
groups  in  required  by  a  function;  may  be  frac¬ 
tional  for  timeshared  or  multiplexed  resources. 
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